网站icp备案信息查询王也道长头像

like模糊匹配优化

1. 最左匹配原则

2. 无法满足最左，是最右匹配的情况（'%advf'）,可以将这个字段保存一个倒序的值在DB， 就可以对倒序使用最左匹配

3. 增加其他的查询条件，缩小查询范围

4. 缓存， 前提这些数据不怎么变化

5. 使用专业工具：对于非常大的数据集 或者 需要复杂文本处理和搜索功能， 可以使用外部全文搜索引擎如ES、Solr来替代Mysql

sql用了函数会导致索引失效吗

失效：        

• 对索引列使用函数 -》 失效
• 对索引列使用计算表达式 -》 失效

不失效：

        函数在索引范围之外

优化意见：

• 使用函数后的结果新增加一列
• 在应用层做函数计算，而不是在sql层
• 在代码上生产前，一定要先用EXPLAIN分析和验证是有有效的使用了索引

索引失效效率更优的场景

1. 小表
2. 查询的数据量占总数据量非常多（30%或者更多）
3. 范围值很少的列（导致查出的结果非常多）
4. 频繁更新的表（索引维护开销）
5. 复杂查询的优化
6. 数据分布与SQL优化器误判, 特定场景下，Mysql错误估计数据分布或行数

TRUNCATE/ DELETE/DROP

Mysql8 跳跃扫描

1. 分区扫描

2. 应用条件

3. 跳过无关分区

区分度不高的字段建立索引一定没用吗

        一般区分度不高的字段无需建立索引，因为查询还是查出大部分数据，和全表扫描无异；另外索引的维护带来性能开销。

何时低选择性索引可能有用：

1. 固定值查询

        如果应用程序中有特定固定值或特定过滤条件经常被使用，并要求快速响应（如状态标志字段），索引仍然可能提高查询速度。

2. 结合其他高选择性条件

3.覆盖索引的一部分

4. 大数据集中的特定场合

        在数据大的数据集中，占用少量数据的字段索引 可能仍然有助于减少所需的扫描行。

5.统计分析和报告

        如果索引用于统计或聚合操作，通过索引可能更高效的进行分组

Mysql索引结构

B+树

SQL执行过程

连接器->分析器-》优化器-》执行器-》执行引擎

日志：

1. redo log  buffer + redo log磁盘（顺序写）
2. undo log磁盘
3. binlog磁盘

数据表的磁盘文件

Buffer Pool

ACID保障方式

数据库锁

从锁的粒度划分：

1. 行锁：共享锁、排他锁、自增锁
2. 表锁：表共享读锁、表排他写锁、意向锁
3. 全局锁：

加锁算法：

1. 更新操作会自动加排他锁
2. 间隙锁
3. Next-key：间隙锁+右记录锁

聚集索引和非聚集索引

聚集索引优势

1. 直接获取数据，不需要回表
2. 支持范围查询
3. 适合排序的场合

聚集索引劣势

1. 维护索引成本高，在插入新行或者主键被更新，可能导致分页，另外数据移动可能会产生内存碎片。
2. 如果使用UUID作为主键（或者随机id），导致数据存储稀疏，数据查询性能也降低。因为查询数据时按照页加载到内存， 稀疏的页肯定对查询性能有影响。
3. 如果主键比较大，非聚集索引会存储更多的内容，占用更多的物理空间

慢Mysql优化

1. 是否加索引
2. 是否是最右索引
3. 覆盖索引
4. 是否数据库的数据量太大了，是否需要分库分表
5. 机器配置是否太低

数据库存储引擎

查看数据库支持的存储引擎：show engines;

不同存储引擎之间的区别：

5、索引结构不同

分库分表主键

• UUID：性能好，无顺序， 泄露硬件地址
• 数据库主键：强依赖主键、扩展不方便、业务泄露、性能瓶颈
• 雪花算法：
• redis等组件：