like模糊匹配优化
-
最左匹配原则
-
无法满足最左，是最右匹配的情况（'%advf'）,可以将这个字段保存一个倒序的值在DB， 就可以对倒序使用最左匹配
-
增加其他的查询条件，缩小查询范围
-
缓存， 前提这些数据不怎么变化
-
使用专业工具：对于非常大的数据集 或者 需要复杂文本处理和搜索功能， 可以使用外部全文搜索引擎如ES、Solr来替代Mysql
sql用了函数会导致索引失效吗
失效：
- 对索引列使用函数 -》 失效
- 对索引列使用计算表达式 -》 失效
不失效：
函数在索引范围之外
优化意见：
- 使用函数后的结果新增加一列
- 在应用层做函数计算，而不是在sql层
- 在代码上生产前，一定要先用EXPLAIN分析和验证是有有效的使用了索引
索引失效效率更优的场景
- 小表
- 查询的数据量占总数据量非常多（30%或者更多）
- 范围值很少的列（导致查出的结果非常多）
- 频繁更新的表（索引维护开销）
- 复杂查询的优化
- 数据分布与SQL优化器误判, 特定场景下，Mysql错误估计数据分布或行数
TRUNCATE/ DELETE/DROP
Mysql8 跳跃扫描
-
分区扫描
-
应用条件
-
跳过无关分区
区分度不高的字段建立索引一定没用吗
一般区分度不高的字段无需建立索引，因为查询还是查出大部分数据，和全表扫描无异；另外索引的维护带来性能开销。
何时低选择性索引可能有用：
- 固定值查询
如果应用程序中有特定固定值 或特定过滤条件经常被使用，并要求快速响应（如状态标志字段），索引仍然可能提高查询速度。
- 结合其他高选择性条件
3.覆盖索引的一部分
- 大数据集中的特定场合
在数据大的数据集中，占用少量数据的字段索引 可能仍然有助于减少所需的扫描行。
5.统计分析和报告
如果索引用于统计或聚合操作，通过索引可能更高效的进行分组
Mysql索引结构
B+树
SQL执行过程
连接器->分析器-》优化器-》执行器-》执行引擎
日志：
- redo log buffer + redo log磁盘（顺序写）
- undo log磁盘
- binlog磁盘
数据表的磁盘文件
Buffer Pool
ACID保障方式
数据库锁
从锁的粒度划分：
- 行锁：共享锁、排他锁、自增锁
- 表锁：表共享读锁、表排他写锁、意向锁
- 全局锁：
加锁算法：
- 更新操作会自动加排他锁
- 间隙锁
- Next-key：间隙锁+右记录锁
聚集索引和非聚集索引
聚集索引优势
- 直接获取数据，不需要回表
- 支持范围查询
- 适合排序的场合
聚集索引劣势
- 维护索引成本高，在插入新行或者主键被更新，可能导致分页，另外数据移动可能会产生内存碎片。
- 如果使用UUID作为主键（或者随机id），导致数据存储稀疏，数据查询性能也降低。因为查询数据时按照页加载到内存， 稀疏的页肯定对查询性能有影响。
- 如果主键比较大，非聚集索引会存储更多的内容，占用更多的物理空间
慢Mysql优化
- 是否加索引
- 是否是最右索引
- 覆盖索引
- 是否数据库的数据量太大了，是否需要分库分表
- 机器配置是否太低
数据库存储引擎
查看数据库支持的存储引擎：show engines;
不同存储引擎之间的区别：
5、索引结构不同
分库分表主键
- UUID：性能好，无顺序， 泄露硬件地址
- 数据库主键：强依赖主键、扩展不方便、业务泄露、性能瓶颈
- 雪花算法：
- redis等组件：