SQL 架构优化是否一定要上中间件？

多数中小规模场景应优先做「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 层转移到了中间层。没想清楚谁来维护这层逻辑、怎么定位跨节点问题，就等于给系统埋了个定时炸弹。