连接池配置不当会掩盖索引失效问题
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），避免连接因服务端主动断开而抛出
CommunicationsExceptionDruid 中开启
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都管用。
