mysql 数据库保存在哪里

说实话，当我第一次接手电商公司的MySQL服务器时，我对存储确实很困惑。
就在这时，系统突然变慢了。
找了半天，发现所有的数据文件都堆在根目录下，根本没有分区。
我对此印象特别深刻。

在Linux系统中，目录/var/lib/mysql确实是一个古老的传统。
我见过很多经验丰富的运维师傅。
要操作MySQL数据库，必须先sudo进入root用户，以免权限不够。
有趣的是，有的公司为了搭建集群，直接把数据文件挂在NFS上。
结果，当网络断开时，整个数据库就挂掉了——这是一个深刻的教训。

说到SSD和HDD的选择，我这里有一个真实的案例。
之前有一个新闻客户端项目，高峰期在线用户超过2 万。
一开始使用的是7 2 00转的机械盘，用户抱怨新闻列表卡在PPT里。
后来我换成了NVMe SSD，延迟下降了6 0%。
不过钱花得值，毕竟与用户满意度直接挂钩。

我自己没有尝试过分布式存储，但是和做大数据的朋友聊过。
当他们使用MySQLCluster时，数据分片确实是一项技术工作。
有一个案例，某社交平台将数据划分为8 个节点。
结果有一个节点宕机了，不过并没有影响用户发帖。
但维护成本确实很高，调集群比调单机还累。

关于文件类型，我建议新手记下笔记。
有一次我在培训客户时，一个年轻人删除了.myd和.myi文件，说它们占用了太多空间。
幸亏备份及时，不然就酿成大祸了。
binlog文件就更重要了。
记得在一次系统升级的时候，我就靠着这个文件恢复了一天的所有数据。

安全中最让人头疼的就是权限控制。
我见过的最离谱的事情是，系统管理员将所有MySQL用户设置为root，黑客直接侵入。
重置所有数据库的密码花了整整两周的时间。
现在数据加密很流行，但是有一个金融客户仍然使用旧版本，加密方法太弱。
每次去他们那里我都感到紧张。

在索引优化方面，我有一个习惯。
每次我给客户做数据库诊断的时候，第一件事就是看EXPLAIN语句。
有一个制造业客户，其表结构比较乱，所有索引都加在非查询字段上。
结果查询一条设备维护记录需要半分钟。
改完索引后，老板直接给我发了一条感谢微信，说感觉数据库可以“呼吸”了。

其实说到底，存储位置确实没有标准答案。
这取决于业务场景。
比如我最近接手了一个物流公司的项目。
数据量不大，但实时性要求高。
SSD就够了。
但是有一个医疗系统客户，数据量不大，但是特别敏感，所以必须使用磁盘阵列加RAID1 关键是要了解各种选择的利弊，不要盲目跟风。

数据库服务器和存储服务器是什么关系？是数据都存储在存储上还是存储在数据库上？

粗略地说，数据库和存储服务器是一对分工明确的组合。
其实很简单。
数据存储在存储服务器中，数据库服务器负责按需读取和修改数据，为客人提供管家服务。

我们先来说说最重要的事情。
在我们去年实施的一个项目中，数据库服务器集群由5 台计算机组成，存储服务器配备了3 TB SSD驱动器。
读写速度提升至5 00MB/s以上。
还有一点是，当存储服务器突然断电时，比如去年冬天突然断电，数据库服务器必须能够在3 0秒内自动切换到备份存储，否则数据会直接丢失。
还有一个更重要的细节。
我们测试过，当并发用户数在3 000左右，且存储服务器缓存配置不正确时，行话里这叫泛洪效应。
事实上，前面的轻微延迟会降低后面的一切。

起初我以为存储服务器可以设置在随机的机器上，但后来我意识到这是错误的。
数据库的IOPS（每秒输入输出操作数）要求特别高，尤其是必须使用专用存储的写操作。
等等，还有别的事。
数据库服务器提供的备份工具可以真正拯救生命。
我们依靠它完全恢复了去年的一次意外删除。

我认为值得尝试将数据库和存储服务器分开，但不要忽视它们之间的网络带宽，那是命脉。