打开一个电商网站，据库用户搜索“蓝牙耳机”，网站0.3秒后返回上千条结果。据库这背后大概率是网站MySQL在干活。不是据库因为它最快，也不是网站因为它最先进，而是据库它足够稳，稳到大多数团队根本懒得换。网站

我见过一个日活三十万的据库小程序，后台就一台4核8G的网站云服务器，MySQL 5.7跑着，据库QPS峰值冲到两千多，网站CPU还没吃满。据库老板问要不要换分布式数据库，网站技术负责人回了一句：等它扛不住了再说。据库这话听着不负责，但其实是很多中小型网站的真实状态——MySQL不是瓶颈，业务逻辑才是。

为什么是MySQL，不是别的

PostgreSQL功能更强，MongoDB写起来更自由，Redis快得离谱。但MySQL赢在一个很土的理由：会的人多。招一个后端，简历上写“熟悉MySQL”是默认项，写“精通PostgreSQL”你得先问问他真用过还是只跟过教程。网站上线初期，能快速找到人修问题比什么都重要。

另一个原因是生态。WordPress、Drupal、Typecho，这些建站系统默认就是MySQL。你买虚拟主机，控制面板里一键安装的数据库，八成也是MySQL。网站从零到一的时候，没人会为了“技术先进性”去折腾数据库选型。

一个真实的慢查询案例

去年帮朋友看一个论坛网站，首页加载要6秒。服务器配置不差，8核16G，MySQL 8.0。慢查询日志里有一条SQL跑了4.2秒：SELECT * FROM posts WHERE status = 1 ORDER BY created_at DESC LIMIT 20。表里才八十万行，按理说不该这么慢。

explain一看，type是ALL，全表扫描。status字段没索引，created_at也没索引。加了一个联合索引(status, created_at)之后，同样的查询降到0.02秒。朋友问我为什么不早点告诉他，我说你也没问过。很多网站的性能问题，不是MySQL不行，是建表的时候根本没想过数据会涨到八十万行。

连接池这事，比你想的重要

网站代码里每一次new mysqli()或者createConnection()，都是一次TCP握手加MySQL认证。并发一上来，连接数暴涨，MySQL的max_connections默认才151。超了就直接报“Too many connections”，网站白屏。

连接池不是万能的，但没有连接池是万万不能的。PHP-FPM环境下，每个请求独立进程，不用连接池的话，数据库连接数跟并发数成正比。一个日PV十万的网站，晚高峰同时几百个请求，MySQL直接被打满。用pconnect或者上ProxySQL、MySQL Router做中间层，情况会好很多。我自己的习惯是，任何要上线的网站，先确认连接池方案再写业务代码。

备份这件事，别等出事再想

有个做外贸独立站的朋友，MySQL跑在阿里云RDS上，觉得云服务商自动备份就够了。结果某天运营误操作，把一张核心产品表清空了。RDS的自动备份是每天凌晨一次，恢复到最近的时间点，当天的数据全丢。他问我怎么办，我说只能接受丢一天数据，或者从binlog里挖。后来花了三千块找数据恢复公司，找回来八成。

MySQL的binlog是个好东西，但默认不一定开。就算开了，保留时间也可能只有几天。网站稍微有点用户数据，就该把binlog_format设成ROW，expire_logs_days至少7天，再搞个定时任务把备份拉到另一台机器上。别问“要不要”，问就是“必须”。

MySQL不是终点

当单表过亿，当写入量撑不住，当业务需要跨地域多活，MySQL确实会吃力。分库分表、读写分离、上TiDB或者OceanBase，都是可选路径。但大多数网站活不到那一天。先把索引建对，把慢查询干掉，把连接池配好，把备份做实。这些事做完，MySQL还能陪你走很远。

技术选型没有银弹，只有合不合适。MySQL不酷，但它让网站先跑起来。跑起来之后的事，跑起来再说。

(责任编辑：探索)