MySQL不适合做什么
MySQL是OLTP（OnLine Transaction Processsing 联机事务处理）数据库，相较于OLAP（Online Analytical Processing 联机分析处理）数据量小，查询简单。
Mysql是磁盘数据库，基于磁盘IO，相较于Redis内存型数据库，速度慢上不少。
综上：
- 海量数据查询：MySQL不香吗，为啥还要Elasticsearch
- 大数据文本检索：为什么 Mysql 不适合大数据文本检索
- 热点数据查询：基于磁盘IO（bufferPool）
- 实时数据
Mysql数量级达到一种什么量级可能会存在一些性能问题
2kw条数据左右性能会有下降，当然这是在硬件配置不够的情况下，传统的说法是大于2kw，B+树索引就达到了4层，随机IO拉低了查询效率。但是在现在的SSD场景下，多出的几次随机IO也无关紧要。
实际上是在高出三层后，如果内存不够大，实际上buffer pool只能够缓存前三层的非叶子节点，最后一层只能够进行磁盘随机IO。所以会显现出效率断层下降的情况，说到底还是硬件不够好，应该加核心，上内存。
Mysql到达什么量级去考虑做分库分表
达到单表性能较低的时候，这个没办法衡量，主要和当前的硬件水平以及所处场景相关。
一般是当并发量很高或磁盘不够用了会去选择分库。
当单表数据量很大，硬件无法提升，SQL优化，索引都尝试过了才会去选择分表。
如果非要说一个数字，那么阿里巴巴的《Java开发手册》提出：
单表行数超过
500万行或者单表容量超过2GB，才推荐进行分库分表。
当然应该已经过时了。
建表一般会遵守什么原则或者规范
- 命名：小写+下划线
- 使用InnoDB 存储引擎
- 使用UTF8MB4
- 加注释
- 优先选择占用存储空间小的类型
- 尽可能的设置NOT NULL
- 使用timestamp代替datetime
- 考虑可能的SQL，充分利用索引（索引覆盖等等，索引的知识）
- 主键单机选择自增，分布式选择雪花（个人）
- 通用字段：create_time,update_time,del_flag,version（乐观锁）等
MySQL什么时候会全表扫描
用不上索引：对于一条SQL，没有建立索引或者索引失效。
优化器发现使用索引的效率低于全表
使用索引后，大部分情况是是随机IO一次读一条，假设次数是T
使用全表，一次读一页，假设读取次数是B页
如果T大于B，那么就不使用索引而采用全表扫描。
MySQL表里有5亿的数据，分页查询怎么实现
先介绍深度分页，为什么深度分页慢（分页的本质：舍弃）。然后说怎么做：
- 业务上避免随机深度分页
- 可以采用子查询降低查询代价
https://blog.csdn.net/weixin_40834464/article/details/107351181