多数中小规模场景应优先做「SQL + 表结构 + 索引」三板斧，中间件是基础优化触达瓶颈后的进阶手段，而非默认解药；盲目引入反致延迟增加10–30ms。
不一定要上中间件，多数中小规模场景反而该先做「SQL + 表结构 + 索引」三板斧
中间件不是性能问题的默认解药，而是当基础优化触达瓶颈后的进阶手段。很多团队一遇到慢查询就想着引入 ShardingSphere 或 MyCat，结果发现 QPS 没涨，延迟反而多了 10–30ms——因为多了一层网络转发和 SQL 解析开销。
真实压测数据表明：在单库 QPS
- 用
EXPLAIN定位全表扫描，给WHERE/ORDER BY字段补索引（注意避免JSON列或函数包裹字段） - 把大字段（如
TEXT、BLOB）拆到扩展表，主表只留高频查询字段 - 将频繁 JOIN 的维度表冗余关键字段（反范式），减少联表次数
- 用
UNION ALL替代UNION，显式关闭去重逻辑
什么时候真该考虑中间件？看这三个硬指标
中间件的价值体现在「不可绕过」的扩展性瓶颈上，不是“看起来很酷”。符合任一条件，才值得评估：
- 单表行数持续 > 5000 万，且
INSERT/UPDATE频繁导致主键自增锁争用（尤其InnoDB下） - 读写分离已上线，但从库复制延迟仍长期 > 2s，业务无法容忍脏读又不愿改代码加
SELECT ... FOR UPDATE - 跨库事务成为常态（如订单库+库存库+积分库同时扣减），而应用层靠消息+补偿已难以兜住一致性
注意：Redis 缓存属于「读加速中间件」，但它不解决写扩展问题；它能扛住 80% 的热查询，但不能替代分库分表决策。
选 Proxy 还是 Client 模式？别被文档忽悠，看运维和开发谁背锅
Proxy 模式（如 ShardingSphere-Proxy）对应用零侵入，但所有 SQL 流量必经一层 TCP 转发，网络抖动会直接放大成数据库超时；Client 模式（如 ShardingSphere-JDBC）嵌在应用里，省了网络跳，却要求每个服务都升级 SDK、管理分片规则配置。
- 如果你的 DBA 团队强于网络运维，且 Java 服务版本混乱（Spring Boot 2.x / 3.x 并存），优先选
Proxy - 如果你的 DevOps 工具链成熟（CI/CD 自动注入配置、灰度发布可控），且希望规避
max_connections突增风险，Client更稳 - 千万别混用：同一套分片规则在 Proxy 和 Client 里各配一遍，极易出现路由错位，查不到数据还报
ERROR 1146 (42S02): Table doesn't exist
上了中间件，最常被忽略的其实是「监控盲区」
中间件自身不产生业务数据，但它的异常会静默放大数据库问题。比如：ShardingSphere 的 SQL 路由失败，默认返回空结果而非报错；MyCat 的连接池耗尽时，应用日志只显示 Connection refused，根本看不出是中间件崩了还是 MySQL 崩了。
- 必须暴露中间件的
/actuator/metrics（Spring Boot）或admin port（Proxy），重点盯shardingsphere.sql.execute.time.max和shardingsphere.connection.leak.count - 在慢查询日志里加
/* SHARDING_KEY=12345 */注释，方便追踪某条 SQL 实际落到哪个物理库表 - 禁止关闭中间件的 SQL 重写日志（
sql-show=true），否则排查GROUP BY聚合错误时，你连原始语句长什么样都不知道
中间件不是银弹，它是把数据库的复杂性从 SQL 层转移到了中间层。没想清楚谁来维护这层逻辑、怎么定位跨节点问题，就等于给系统埋了个定时炸弹。
