很多开发做项目的时候，数据库这块经常容易忽视。大家更多精力放在业务功能开发上，等到数据量变多、查询变慢，才回头处理数据库问题，这个时候改起来成本很高。结合我们平时项目里的经验，简单聊聊数据库相关的一些实际做法。
选数据库不要跟风选热门的。现在数据库种类很多，关系型、非关系型各种各样，网上很多文章会推荐新库，看着性能参数很好。但选型优先看业务场景。如果数据结构固定，事务要求高，订单、用户信息这类数据，优先用关系型数据库，稳定，出问题也好排查。如果是日志、埋点、临时统计数据，读写量很大，结构经常变，可以考虑非关系型数据库。不要为了技术时髦，强行换数据库，后期维护、招人、排查故障都会麻烦。
表结构设计尽量简单，不要一开始就设计得很复杂。很多人建表喜欢一次性把所有字段都加上，预留很多暂时用不上的字段。字段越多，索引越难维护。能拆分的表就拆分，但是也别过度拆分，表太多关联查询反而慢。字段类型选合适的，能用小类型就不用大类型，时间字段不要存字符串，主键尽量简单。注释一定要写，过几个月再回头看表结构，很容易记不清字段用途。
索引是提升查询速度最直接的办法，但不能乱建。索引不是越多越好。新增、修改数据的时候，索引也会跟着更新，索引太多，写入速度会下降。只给经常用来查询、筛选的字段建索引。联合索引要注意顺序，区分度高的字段放前面。写完 SQL 之后，最好看一下执行计划，确认 SQL 有没有正常走到索引。经常碰到写了索引，但是 SQL 写法不对，索引没生效的情况。
SQL 语句尽量写简单一点。不要写太长、嵌套多层的 SQL，复杂 SQL 数据库优化起来吃力，后期别的同事接手也看不懂。尽量避免 select *，只查业务真正需要的字段。大批量数据不要一次性查出来，分页查询，控制单次返回的数据量。批量插入、更新数据的时候，分批处理，防止锁表，影响其他用户使用。
做好数据备份，这件事没有商量余地。很多事故都是备份不到位。定时自动备份之外，一定要定期测试备份文件能不能正常恢复。只备份不验证，等于没有备份。还要区分全量备份和增量备份，根据数据更新频率调整备份周期。重要业务，异地备份也要考虑，防止服务器硬件故障带来数据丢失。
监控和慢查询要长期盯着。数据库不会一下子崩掉，性能问题是慢慢积累的。开启慢查询日志，定期拿出来分析，找到执行慢的语句优化。监控关注 CPU、内存、连接数、磁盘 IO 这些指标，设置告警。不要等到数据库卡死、业务报错了才发现问题。
最后说下扩容。数据涨起来之后，最先考虑优化 SQL、优化索引、清理无用数据。这些办法做完还不够，再考虑分库分表。分库分表改动大，业务代码改动多，后续运维成本高，属于最后手段，不要一上来就规划分库分表。
数据库本身不难，难在长期稳定运行。大部分线上数据库故障，不是数据库本身有 bug，而是前期设计随意、SQL 不规范、缺少备份和监控。把基础规范落实好，就能避开大部分问题。