Mysql慢查询的考虑

说实话，搞MySQL慢查询这事儿，我当年也是摸着石头过河过来的。
给你说说我的体会，可能有点跑偏，但都是真事儿。

先说那个阈值吧。
我们当时做系统的时候，一开始设的是1 秒，后来发现用户反馈慢得慌。
说实话，我这人比较急，就改成0.5 秒了。
但有意思的是，后来发现有些复杂查询，比如跨库关联查询，可能0.5 秒都跑不够。
所以后来我们干脆按业务场景定，像订单查询这种高频操作，阈值设到0.2 秒；而报表生成这种，3 秒都算快。
这事儿真不能一刀切。

说到慢查询原因，我印象最深的是有一次系统突然卡死。
查了半天，发现是某个老哥写的查询，把三个大表的ID用字符串拼接起来做WHERE条件。
当时我就震惊了，这简直是在跟MySQL较劲。
还有一次，是磁盘I/O瓶颈。
那天我们服务器突然换硬盘，从SSD换回机械盘，结果慢查询直接翻倍。
数据量大的问题更常见，我记得有一次查某个用户历史交易记录，没加LIMIT，直接把十几万条数据灌出来，整条线都卡了。

优化这块，索引绝对是重头戏。
我有个习惯，每次写SQL都会先想这字段要不要加索引。
比如我们系统里用户名那字段，选择性极高，基本查必加索引。
但后来发现过度索引也不好，有一次批量更新用户头像，因为用户名、邮箱、手机号都加了索引，结果写入延迟直接飙升。
所以现在我们规定，单表索引不超过5 个。
OPTIMIZE TABLE这命令，我们一般是凌晨搞，毕竟白天搞影响用户。

慢查询日志这东西，绝对是救星。
我们那个日志文件，当时直接开在SSD上。
每天早上运维会先扫一遍，找出TOP 1 0的慢查询。
我有个习惯，看到SQL语句特别长，比如JOIN了十几个表还不带LIMIT的，直接就删了或者重构。
Percona Toolkit里的pt-query-digest，用起来真顺手，能自动分类慢查询原因。

监控工具这块，EXPLAIN我天天用。
有一次我看一个查询EXPLAIN出来的Extra里写着"Using temporary table"，当时我就觉得不对劲，查了半天发现WHERE条件里有个计算函数，结果索引失效了。
MySQLTuner这工具，我挺推荐的，调参数挺方便。

不过说实话，这块我也有没跑过的。
比如分布式数据库的慢查询怎么看，我这经验就不足。
数据我记得是X秒左右，但建议你核实下版本差异。
总之，慢查询这事儿吧，真得结合具体情况来搞，不能光靠套公式。

mysql开启慢查询怎么把每天日志文件分开

确定慢查询是关键，MySQL慢日志记录慢SQL。
检查MySQL版本和配置，确保慢日志开启。
配置慢日志文件路径、时间阈值、记录无索引查询和管理命令。
从3 秒开始，逐步减少时间阈值，优化最慢的1 0条SQL。
无索引查询要关注，可能隐藏性能问题。
管理命令记录有助于发现潜在问题。
你自己掂量。