连接池配置不当会掩盖索引失效问题：未走索引的慢查询被复用连接反复执行，导致DBA误判为连接泄漏；EXPLAIN中key为NULL即表明索引缺失，此时调优连接池无效，应优先优化索引与SQL。
连接池配置不当会掩盖索引失效问题
MySQL 连接池（如 HikariCP、Druid）本身不干预 SQL 执行计划，但它的复用机制会让「慢查询被缓存连接反复执行」，掩盖本该由索引优化解决的性能瓶颈。比如一个未走索引的 SELECT * FROM orders WHERE status = 'pending'，在连接池中可能持续占用连接、堆积等待，而 DBA 只看到连接数高，误判为连接泄漏。
- 检查慢查询日志时，务必同步开启
log_queries_not_using_indexes = ON，否则连接池掩盖下的全表扫描不会被记录 - 连接池的
maxLifetime建议设为略小于 MySQL 的wait_timeout（如 MySQL 设 28800 秒，HikariCP 设 25200），避免连接因服务端主动断开而抛出CommunicationsException - Druid 中开启
testOnBorrow = true+validationQuery = SELECT 1能暴露网络或权限类问题，但无法检测索引缺失——这类问题必须靠EXPLAIN定位
EXPLAIN 结果里 key 为 NULL 就别急着调连接池
当 EXPLAIN SELECT ... 返回的 key 列是 NULL，说明这条语句根本没用上索引，此时加连接数、调 maximumPoolSize 只会让数据库负载雪上加霜。重点应放在索引设计和查询重写上。
- 复合索引顺序必须匹配
WHERE条件的最左前缀：对WHERE user_id = ? AND status = ? ORDER BY created_at DESC，索引应建为(user_id, status, created_at)，而非(status, user_id) - 避免在索引列上使用函数或运算：
WHERE DATE(created_at) = '2024-01-01'会跳过索引；改用WHERE created_at >= '2024-01-01' AND created_at -
LIKE查询以通配符开头（LIKE '%abc'）无法使用 B+ 树索引，考虑全文索引或倒排表替代
连接池监控要叠加 SQL 级性能指标
只看连接池的 activeConnections 或 idleConnections 没意义。必须把每条执行 SQL 的 EXPLAIN 输出、执行时间、扫描行数（rows）和是否命中索引（key）关联起来分析。
- HikariCP 不提供 SQL 级埋点，需配合代理层（如 ShardingSphere-JDBC）或 AOP 拦截
PreparedStatement.execute*方法，记录绑定参数与耗时 - Druid 内置
stat-view-servlet，开启后可查看SQL 监控页面，重点关注「执行次数多且平均毫秒高」+「逻辑扫描行数 / 影响行数比值大」的语句 - 对高频查询，强制指定索引可临时止损：
SELECT * FROM users USE INDEX (idx_email) WHERE email = ?，但这是权宜之计，长期仍需检查统计信息是否过期（ANALYZE TABLE users）
批量操作时连接池与索引的协同陷阱
用连接池执行批量插入/更新时，若目标表有大量二级索引，每条语句都会触发索引维护开销。这时盲目增大连接池并发数，反而导致磁盘 I/O 和锁竞争加剧。
- 批量插入前，考虑临时禁用非关键索引：
ALTER TABLE logs DROP INDEX idx_trace_id，导入完成后再重建（注意主键和唯一索引不可禁用） - 批量更新慎用
IN子句：当UPDATE orders SET status = 'done' WHERE id IN (1,2,...,5000)，若id是主键，没问题；但若条件字段无索引，MySQL 可能退化为全表扫描 + 逐行判断 - 分页查询带排序时，避免
LIMIT 10000, 20：即使有索引，MySQL 仍需定位前 10000 行。改用游标式分页：WHERE created_at
EXPLAIN SELECT * FROM products WHERE category_id = 5 AND price < 100 ORDER BY updated_at DESC LIMIT 20;
真正卡住系统的，往往不是连接池满了，而是某条没走索引的查询占满 IO 并锁住行。索引优化是根因，连接池只是表象——调参前先跑一遍 EXPLAIN，比改十次 maximumPoolSize 都管用。
