去年帮一个做跨境电商的网站朋友救火，他的后台独立站后台崩了。用户下单后订单数据写不进去，数据前端页面转圈转到超时。库搭我登上服务器一看，网站MySQL的后台InnoDB日志文件把磁盘撑爆了，binlog三天没清理。数据他之前图省事，库搭数据库直接跑在应用服务器上，网站配置全是后台默认值。这事让我觉得，数据后台数据库搭建这件事，库搭值得掰开揉碎说几句。网站

选型是后台第一道坎。很多人上来就问“MySQL和PostgreSQL哪个好”，数据这问题本身就不对。我自己的习惯是看业务形态。如果后台主要是CMS内容管理、订单流水这种读多写少、结构清晰的场景，MySQL配InnoDB足够稳，运维资料也多，出了问题搜得到答案。但要是后台涉及地理空间查询、JSON字段频繁读写、复杂事务嵌套，PostgreSQL的优势就出来了。我见过一个做本地生活服务的团队，用MySQL存门店坐标，做“附近3公里”查询时硬生生用经纬度字段加索引算距离，慢得离谱。换成PostGIS，一条SQL就解决。选型不是选最好的，是选最合身的。

表结构设计这块，踩坑的人最多。有个做SaaS后台的开发者跟我聊，他给每个租户建了一张独立表，租户过千之后，数据库里几千张表，每次升级加字段要写脚本遍历执行，苦不堪言。后来改成共享表加tenant_id字段，配合行级权限，清爽多了。我的经验是，除非有硬性合规隔离要求，否则别轻易分表到这种粒度。字段类型也别乱来。见过用varchar(255)存用户ID的，也见过用text存手机号的，索引效率低不说，数据校验全压在应用层。该用int就用int，该用datetime就别用字符串。

索引是另一个重灾区。后台管理界面通常有大量筛选和排序操作，开发者一看慢查询就加索引，加到最后写入性能暴跌。我自己的判断标准是：单表索引数量控制在5个以内，复合索引注意最左前缀原则。有个案例印象很深，一个订单后台按状态、创建时间、用户ID三个条件组合查询，开发者分别建了三个单列索引，MySQL查询优化器最后只选了一个，另外两个白建。改成(status, created_at, user_id)的复合索引后，查询从2秒降到20毫秒。索引不是越多越好，是越准越好。

连接池配置经常被忽略。默认的max_connections设成151，看起来够用，但后台应用如果用HikariCP这类连接池，每个实例默认10个连接，部署5个实例就是50个，再加上定时任务、运维脚本、监控采集，并发一上来直接打满。我一般会把max_connections调到500以上，同时设置wait_timeout让空闲连接及时释放。还有个细节：后台数据库和前端业务库最好物理隔离，至少用不同实例。后台的批量导出、数据修正操作很容易把连接数吃光，影响线上交易。

备份策略不能只靠云厂商的自动快照。我见过一个团队，云数据库自动备份保留7天，结果一个运营误删了重要配置表，等到第三天发现时，备份已经被新数据覆盖了。后来他们改成每天凌晨逻辑备份到对象存储，保留30天，每周做一次恢复演练。备份文件一定要验证可恢复性，否则就是心理安慰。binlog也要开，保留时间根据业务容忍度设，至少72小时。

监控和慢查询日志是日常运维的眼睛。后台数据库的QPS通常不高，但单条SQL可能很重。开启slow_query_log，设置long_query_time=1秒，每周 review 一次。Prometheus加mysqld_exporter采集指标，重点关注连接数、缓冲池命中率、磁盘IO等待。有次我发现缓冲池命中率从99%掉到85%，查下来是一个新上线的报表功能全表扫描，加了索引就恢复了。数据库搭建不是一劳永逸的事，它更像养鱼，水质要天天看。