元宿six1. 为什么MySQL单独使用会遇到瓶颈？
我做了十年数据库架构，见过太多团队在MySQL单表数据量突破千万级后陷入性能泥潭。这就像让一辆家用轿车去跑拉力赛——不是不能跑，但迟早会散架。
1.1 数据量天花板问题
MySQL单表数据量建议控制在千万级以内，这不是MySQL的缺陷，而是B+树索引结构的特性决定的。当单表数据超过2000万行时，索引高度会增加到4层，随机IO次数暴增。我去年优化过一个电商平台的商品表，单表1.2亿数据时查询延迟从20ms飙升到800ms。
解决方案通常有三种：
- 水平分表：按ID范围或哈希值拆分
- 垂直分表：将大字段分离到扩展表
- 归档历史数据（但业务查询会变复杂）
1.2 全文检索的先天不足
MySQL的ngram全文索引就像用瑞士军刀砍树——它能工作，但你会怀念电锯。我测试过在500万文章的表中：
- LIKE '%关键词%' 需要12秒
- ngram全文索引需要1.8秒
- 相同数据在ES中仅需23毫秒
更致命的是，ngram不支持：
- 同义词扩展（搜索"手机"找不到"智能手机"）
- 词干提取（搜索"running"找不到"run"）
- 相关性评分（无法按匹配度排序）
1.3 组合索引的排列组合灾难
假设有个商品表需要按"品牌+价格+配置"查询，DBA通常会创建(brand, price, config)的联合索引。但遇到以下查询就失效了：
sql复制SELECT * FROM products
WHERE config='高配' AND price BETWEEN 1000 AND 2000
因为不符合"最左前缀原则"。要覆盖所有组合查询，理论上需要创建6种索引排列，这会导致：
- 索引占用的空间超过数据本身
- 写入性能下降50%以上
- 索引维护成本呈指数增长
实战经验：在汽车之家这类需要多维度筛选的场景，我们曾为单个表创建了17个索引，最终导致每秒只能处理30次写入。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. ElasticSearch的强项与致命伤
2.1 搜索性能的降维打击
ES的倒排索引+分片架构，让它在大数据搜索场景就像装了喷气引擎。我们做过对比测试：
- 在2亿商品数据中模糊搜索"黑色真皮沙发"
- MySQL：12秒（即使有全文索引）