SQL 性能优化梳理

说白了，MySQL性能优化主要从数据库创建和查询两个步骤开始。
其实很简单。
让我总结一下要点。

先说最重要的一点：创作过程中的优化。
例如，对于模式和数据类型优化，应根据实际情况选择合适的整数类型、实数类型、字符串类型和时间类型，避免使用字符串存储时间，而使用整数存储IP。
我去年做的一个项目有大约3 000条数据，我发现使用TinyInt相比Int可以节省很多空间。

还有一点就是索引优化也很重要。
B 树索引和哈希索引各有其优点，但您需要注意它们的范围和限制。
例如，B 树索引非常适合减少查询检索的数据量，但对非最左边列的查询不能使用该索引。
哈希索引适用于需要所有列精确匹配但无法排序的查询。
另一个重要的细节是避免使用索引列作为表达式或函数参数。

看看自己的思绪痕迹，一开始我以为索引越多越好，但后来发现我错了。
索引过多会增加维护成本并影响写入性能。

下一步是查询时间优化。
响应时间、扫描的行数和返回的行数是三个重要指标。
例如，避免查询不相关的列和行，精确指定查询条件。
通过拆分查询和分解相关查询也可以提高效率。

等一下。
还有一个问题。
如果条件字段类型与表结构类型不匹配，MySQL会自动添加转换函数，导致索引失败。
此外，与以 % 开头的查询一样，无法到达索引。

最后，我想谈谈一个简单的陷阱。
值得注意的是 MySQL 5 .7 中的新功能，包括生成列和对 JSON 格式数据的支持。

我认为通过基于关键字段描述和优化查询来分析查询执行计划是值得的。
例如，select_type、type、available_keys、key、key_len、row、extra等字段可以提供优化线索。

简单来说，MySQL性能优化是一个复杂的过程，需要综合考虑很多因素。
我希望这些信息对您有所帮助。

新特性解读 | MySQL 8.0：死锁日志改进

2 02 3 年，朋友的公司升级到MySQL 8 .0，他发现死锁协议特别有用。
他表示，之前使用5 .7 版本时，死锁协议只能看到事务正在等待哪些锁，而看不到它已经持有的锁。
现在 8 .0 版本可以同时查看两者，从而使分析速度更快。

但是，他也遇到了一些问题。
有一次他在RC隔离级别下插入数据，发现死锁日志显示有一个事务持有它正在等待的锁。
他最初以为这是系统故障，但后来意识到这是锁竞争逻辑的正常表现。

例如，他说他的公司有一个带有唯一键约束的表。
当他插入一条记录时，他会持有该记录的锁，同时由于唯一键冲突而必须等待 S 锁。
对于另一笔交易，也必须插入记录。
因为需要添加间隙锁，所以第一个事务上的锁会阻塞它。
这种情况会在日志中显示为“holding the lock you are waiting for”。

他告诉我，这种情况不是系统错误，而是在RC隔离级别下，唯一键冲突检查只适用于当前记录，但插入操作也需要间隙锁来防止幻读。
他表示，MySQL 8 .0认为锁队列中的间隙锁被“持有”，因此日志会显示“它正在等待的锁被持有”。

针对这种情况，他建议结合业务逻辑分析日志，区分不同锁的范围，避免误判。
他还表示，可以通过最小化测试用例、确认日志显示的充分性以及使用 Performance_schema.data_locks 表或 SHOWENGINEINNODBSTATUS 命令来获取更详细的锁定信息来重现死锁场景。

朋友说，虽然日志显示有时会让人困惑，但只要了解其背后的锁竞争机制，就可以使用这个工具更准确地调优数据库性能。
他表示，这让他对公司数据库的稳定性更有信心。
算了，你算了，这个话题有点复杂。