慢查询治理：PolarDB，建议收藏

▌ 技术引导
PolarDB的慢查询治理是数据库性能调优中最头疼的事，特别是当执行计划和索引策略没跟上时，很容易出现查询卡死。我见过最离谱的案例是某个订单表没有合理索引，查询单据状态时全表扫描，直接把CPU干到100%。幸运的是，我们通过分析执行计划、重建索引、调整参数等方式找到问题。在PolarDB中，慢查询治理不仅仅是优化语句，更得从系统层面对索引、连接、锁等资源进行深度介入。

实际操作里，我会用EXPLAIN命令分析执行计划，发现临时表、文件排序、全表扫描等痛点。然后根据使用场景决定是加索引、调整join顺序，还是改写查询。有的时候，把WHERE条件前置、减少子查询、或者用CTE代替嵌套查询，能让执行时间下降90%。但关键是要看锁、连接池、并发数这些隐性因素，不能只盯着SQL写法。

我见过一个项目，因为PolarDB的log文件没及时清理，导致慢查询日志堆积，系统负载飙升。这时候就得考虑调整log_max_size和log_min_duration_threshold，或者用阿里云的监控工具定位具体慢查询。还有些人会在执行计划里看到Use Temporary，这时候先检查有没有合适的索引，再考虑是否需要拆分查询。

另外，PolarDB的参数调优也很关键。比如innodb_buffer_pool_size如果没设置到合理值，会直接影响缓存命中率。还有max_connections和query_cache_size这些参数，如果没针对业务负载做适配，也会成为慢查询的温床。我踩过很多坑，有些是改写SQL，有些是调参数，但大部分是没搞清楚执行流程。

慢查询治理不能只依赖工具，还得靠人。比如索引的创建策略，不能盲目添加，得看查询频率和字段分布。我见过有些人把所有可能的字段都加了索引，结果反而拖慢了写入速度。真正有效的治理，是一件件排查、一次次实验、一个个验证的过程，不是照搬模板。

▌ 技术参考
PolarDB的慢查询治理本质是资源分配和执行流程优化的结合。先看执行计划，用EXPLAIN命令分析，发现临时表、排序、全表扫描这些瓶颈。例如在订单表的查询里，如果WHERE子句包含order_id和user_id，但只有其中一个有索引，系统就会走全表扫描，这时候加联合索引会大幅优化性能。

索引的创建和维护需要特别谨慎。比如某次我们用CREATE INDEX命令加了user_id的索引，结果发现查询仍然没用到，是因为查询里用了OR连接两个条件。这时候得考虑用函数索引或加条件判断，或者直接改写SQL。但要注意，索引多了反而会拖慢写入速度，特别是在高并发场景下。

慢查询日志的配置和分析是治理的起点。默认情况下，PolarDB的slow_query_log会记录执行时间超过1秒的查询，但有些情况下，即使执行时间短，但资源消耗大，也会成为问题。这时候可以调整log_min_duration_threshold参数，比如设置为500ms，让系统更早捕捉到潜在的慢查询。

使用EXPLAIN命令时，注意看type字段是否为index，如果是ALL则说明没有用到索引。比如在PolarDB中，执行EXPLAIN SELECT FROM orders WHERE user_id = 123，如果type是ALL，说明需要为user_id创建索引。但有时候，哈希索引可能更高效，这时候得根据数据分布和查询模式动态调整。

在实际操作中，索引的维护还需要考虑索引的更新频率。比如某次查询使用了user_id和status的联合索引，但status字段的数据类型是VARCHAR，且具有大量重复值，这时候索引的使用率并不高，反而造成资源浪费。这时候可以考虑改用ENUM类型或加索引前做统计，确保索引的有效性。

慢查询治理中，连接池的配置也至关重要。如果连接池设置过小，会导致并发查询排队，影响整体性能。比如在PolarDB中，调整max_connections参数到1000，加上wait_timeout=28800，能有效减少连接建立和销毁的开销。但过大的连接池会占用太多内存，得根据实际业务负载动态调整。

监控工具是治理慢查询的重要手段。比如阿里云的PolarDB控制台能实时查看慢查询的拓扑图，但有时候系统本身没记录足够的信息，这时候需要在实例级别配置slow_query_log。例如在/etc/my.cnf里，添加log_slow_queries=1，log_slow_admin_statements=1，让系统记录更多细节。

另一个常见问题是在查询中使用了JOIN，但没有合理使用索引。比如两个表的JOIN字段是user_id，但其中一个表没有索引，这时候执行计划会显示Using temporary，这时候需要在两个表的user_id上都加索引，或者调整JOIN的顺序。比如先过滤主表，再连接子表，能显著提升性能。

在某些情况下，查询语句本身结构不好，比如用了子查询但没加LIMIT，或者用了NOT IN但可以改用NOT EXISTS。比如在PolarDB中，用EXPLAIN分析后发现，NOT IN的子查询会生成临时表，这时候改用NOT EXISTS，不仅执行计划更优，还能减少资源消耗。

PolarDB的锁问题也容易引发慢查询。比如在高并发下，频繁的排他锁会导致阻塞。这时候可以调整innodb_lock_wait_timeout参数，比如设置成50，让锁等待更高效。或者使用SELECT ... FOR SHARE加锁，避免死锁。但锁的优化需要结合业务场景，不能盲目调整。

有时候慢查询是由于查询缓存未命中导致的。比如在PolarDB中，如果开启query_cache_size，但查询语句包含动态参数，缓存命中率会非常低。这时候建议关闭查询缓存，用其他方式如应用层缓存来优化。或者调整query_cache_type为DEMAND，让缓存只在有SELECT SQL_CACHE时生效。

数据分区和分表策略也是慢查询治理的一部分。比如在PolarDB里，如果某个表未分区，查询时可能会全表扫描。这时候可以考虑使用按时间分区，或者按user_id分表。例如，在创建表时使用PARTITION BY RANGE (year)来分割数据，能显著减少查询扫描量。

索引的使用率评估可以通过SHOW INDEX FROM table_name来查看。比如发现某个索引的使用率不足10%，说明它可能没被有效利用。这时候需要检查查询语句是否符合索引的使用条件，或者是否需要调整索引顺序。比如在WHERE条件中，使用字段顺序会影响索引的使用效率。

在某些业务场景下，PolarDB的默认配置可能不足以应对慢查询。比如对于高并发的金融系统，可以调整innodb_io_capacity为更高的值，比如10000，提升磁盘IO的处理能力。或者在连接池配置中，设置wait_timeout为更大的值，减少连接销毁的开销。

有时候慢查询是由于数据量过大，比如某张表有上亿条数据。这时候可以考虑进行数据归档，把历史数据迁移到其他存储，比如OSS，或者用分库分表的方式，把数据按时间或业务分片处理。比如在PolarDB里，使用CREATE TABLE orders_archive SELECT FROM orders WHERE create_time < '2020-01-01'，然后删除旧数据。

PolarDB的执行计划优化还需要结合统计信息。比如如果某字段的统计信息过时，可能导致执行计划选择错误。这时候可以手动更新统计信息，比如用ANALYZE TABLE命令，或者让系统自动刷新。比如在PolarDB中，使用ANALYZE TABLE orders PARTITION p1，仅更新特定分区的统计信息，减少资源消耗。

在慢查询治理中，查询重写是一个常见手段。比如将SELECT 改为SELECT id, status，减少数据传输量。或者将JOIN改写为子查询，让执行计划更清晰。比如在PolarDB中，将JOIN orders ON users.user_id = orders.user_id 改为SELECT FROM users WHERE user_id IN (SELECT user_id FROM orders WHERE status = 'paid')，减少中间结果集的大小。

最后，某些场景下，使用存储过程或物化视图能显著提升性能。比如在PolarDB中，创建一个物化视图，预计算复杂的JOIN查询，能减少实时计算的压力。或者将重复查询封装成存储过程，减少网络传输和解析开销。但要注意，这些方法可能有副作用，比如锁竞争或数据一致性。