MySQL 的最大内存使用量很大程度上取决于硬件、您的设置和数据库本身。
硬件
硬件是显而易见的部分。 RAM 越多,磁盘越快ftw。不要相信那些每月或每周的新闻信件。 MySQL 不能线性扩展——甚至在 Oracle 硬件上也不能。这比那有点棘手。
底线是:对于您的 MySQL 设置推荐什么没有一般的经验法则。这一切都取决于当前的使用情况或预测。
设置和数据库
MySQL 提供了无数变量和开关来优化其行为。如果遇到问题,您真的需要坐下来阅读(f'ing)手册。
关于数据库——一些重要的限制:
- 表引擎 (
InnoDB, MyISAM, ...)
- 尺寸
- 指数
- 用法
stackoverflow 上的大多数 MySQL 技巧都会告诉您 5-8 个所谓的重要设置。首先,并非所有这些都很重要 - 例如将大量资源分配给 InnoDB 而不使用 InnoDB 没有多大意义,因为这些资源被浪费了。
或者——很多人建议增加max_connection 变量——好吧,他们几乎不知道这也意味着MySQL 将分配更多资源来满足max_connections 的需求——如果需要的话。更明显的解决方案可能是关闭 DBAL 中的数据库连接或降低 wait_timeout 以释放这些线程。
如果你明白我的意思——真的有很多很多东西需要阅读和学习。
引擎
表引擎是一个非常重要的决定,许多人很早就忘记了这些,然后突然发现自己与一个 30 GB 大小的 MyISAM 表发生了冲突,该表锁定并阻塞了他们的整个应用程序。
我并不是说MyISAM 很烂,但InnoDB 可以调整为几乎或几乎与MyISAM 一样快的响应速度,并提供UPDATE 上的行锁定等功能而MyISAM 在写入时锁定整个表。
如果您可以在自己的基础架构上运行 MySQL,您可能还想查看percona server,因为其中包括来自 Facebook 和 Google 等公司的大量贡献(他们知道得很快),它还包括Percona 自己替换 InnoDB,称为 XtraDB。
请参阅我的 percona-server(和-client)设置(在 Ubuntu 上)的要点:http://gist.github.com/637669
尺寸
数据库大小非常非常重要——信不信由你,Intarwebs 上的大多数人从未处理过大型和编写密集的 MySQL 设置,但这些确实存在。有些人会说“使用 PostgreSQL!!!111”之类的话,但我们暂时忽略它们。
底线是:从尺寸上看,要做出关于硬件的决定。你不能真正让一个 80 GB 的数据库在 1 上快速运行
GB RAM。
指数
不是:越多越好。仅需要设置索引,并且必须使用EXPLAIN 检查使用情况。再加上 MySQL 的 EXPLAIN 确实是有限的,但这只是一个开始。
建议配置
关于这些my-large.cnf 和my-medium.cnf 文件——我什至不知道这些文件是为谁而写的。自己动手。
调优入门
tuning primer 是一个很好的开始。这是一个 bash 脚本(提示:你需要 linux),它接受 SHOW VARIABLES 和 SHOW STATUS 的输出并将其包装成希望有用的推荐。如果您的服务器已经运行了一段时间,建议会更好,因为会有数据作为它们的依据。
不过,调音底漆并不是一种神奇的调味汁。您仍然应该阅读它建议更改的所有变量。
阅读
我真的很想推荐mysqlperformanceblog。它是各种 MySQL 相关技巧的绝佳资源。而且不仅是 MySQL,他们还非常了解正确的硬件或 AWS 的推荐设置等。这些人拥有多年的经验。
当然,另一个很棒的资源是planet-mysql。