说说MySQL数据库到底怎么用才算靠谱和实在的方案分享

说说MySQL数据库到底怎么用才算靠谱和实在的方案分享

首先得说,MySQL这东西，就像家里的一把好锤子，你不能指望它啥活儿都能干得像专业工具一样，但用对了方法，盖房子、修家具它都是主力，想让它靠谱又实在，关键不在于你会多高深的“魔法”，而在于把一些基础但至关重要的事情做扎实了。

第一，设计表结构的时候，就得想着以后怎么用。

很多人一开始建表很随意,觉得先把功能实现了再说，这就像盖房子没打好地基，后面楼高了准出问题，这里有几个实在的点：

• 给每张表都设个主键：这是这条记录的身份证号，最好是没啥业务意义的自增数字（AUTO_INCREMENT），别用身份证号、手机号当主键，万一以后要改，牵连太大了，这是几乎所有数据库教材都会强调的第一课。
• 字段类型要抠门点儿：比如存年龄，用 TINYINT 就够了，别动不动就 INT，存金额，用 DECIMAL 别用 FLOAT，避免计算时出现几分钱的误差，存真假值，用 TINYINT(1) 或 BIT，别用字符串存“是/否”，省下来的空间，数据量大了就是性能。
• 别搞太多关联：表与表之间关联（JOIN）是必要的，但别为了追求“完美设计”把一张表拆得七零八落，查个数据要关联七八张表，为了查询快，允许少量重复数据存在（这叫“反范式设计”）是值得的，这个思路在《SQL反模式》这本书里有详细讨论。

第二，SQL语句不能乱写，慢查询是性能杀手。

数据库反应慢,十有八九是SQL语句写得不好，怎么才算写好？

• 一定要用上索引：索引就像书的目录，你要查某个字，总不能一页一页翻吧？经常用来查询、排序、分组的字段，比如用户ID、订单时间、商品分类，就得给它建索引，但索引也不是越多越好，因为增删改数据时，更新索引也要花时间。
• 避免全表扫描：写SQL时要时刻想着，你的条件能不能让数据库用到索引。WHERE name LIKE '%张三'，这种前面带通配符的查询，索引基本就失效了，数据库只能从头到尾扫一遍，尽量写成 WHERE name LIKE '张三%'。
• 只取需要的字段：别动不动就 SELECT *，把不需要的字段也查出来，浪费网络和内存，需要啥就写啥，SELECT id, name, email。

第三，日常维护不能偷懒，预防大于治疗。

数据库不是建好就一劳永逸的,得定期关照它。

• 定期备份！定期备份！定期备份！：这事说三遍都不够，最好能做到“双保险”：每天一次全量备份（把整个数据库备份一遍），每隔几小时一次增量备份（只备份最新的变化），一定要定期恢复演练，确保备份的文件是真的能用的，多少血泪教训都是因为备份文件损坏了无法恢复。
• 监控慢查询日志：MySQL有个功能叫慢查询日志，会把执行时间超过设定值（比如1秒）的SQL都记下来，定期去翻翻这个日志，把里面的“慢SQL”抓出来优化掉，是提升性能最直接的办法，很多公司的DBA每天必看这个。
• 考虑把数据库和应用分开：当访问量大了，一台服务器又跑应用代码又存数据，肯定扛不住，这时候就要做“读写分离”：搞一台主数据库（Master）专门负责写入数据（比如下单、注册），再搞几台从数据库（Slave）专门负责读取数据（比如查询商品、查看订单），应用读数据的时候就去从库读，写数据的时候才去找主库，这个方案非常普遍和实用。

第四，根据业务特点选择最合适的方案。

没有放之四海而皆准的法则,得看你的业务是啥样的。

• 如果是金融、交易类业务，数据一分一毫都不能错，那就要把事务（Transaction）用好，确保一系列操作要么全成功，要么全失败，这时候可以牺牲一点性能来保证绝对的准确。
• 如果是社交、新闻类读多写少的业务，重点就要放在如何提升读取速度上，前面说的读写分离、加缓存（比如用Redis把热点数据存到内存里）就是关键。
• 数据量真的超级大了怎么办？ 比如订单表几年下来几十亿条，查都查不动了，这时候就要“分库分表”，就是把一张大表按某种规则（比如按用户ID或者时间）拆分成很多张小表，分散到不同的数据库服务器上去，这个动作比较“伤筋动骨”，一般是业务发展到很大规模后才考虑的终极方案。

靠谱实在的MySQL使用方案就是：

设计阶段多想一步，编码阶段规范一点，运行阶段勤快一点。 别盲目追求高大上的新技术，先把索引、SQL优化、备份监控这些基本功练到极致，就能解决90%以上的问题，MySQL本身很强大也很稳定，绝大多数情况下，性能瓶颈和问题都出在我们自己的使用方式上，把基础打牢，就是一个最靠谱、最实在的方案。