MYSQL优化

Performance Schema

程序插桩 消费者表

是一个经常受到批评的特性。早期版本的MySQL对其的实现不够理想，导致资源消耗较高。通常的建议是干脆关掉它。

这也被认为是难以理解的。只是启用了一些插桩代码，这些代码用于记录数据并将其提交给消费者表。消费者表是一些内存表，需要使用标准SQL语句查询数据，获取信息。了解了Performance Schema如何管理自己的内存后，你就能认识到MySQL并没有泄漏内存，它只是将消费者数据保存在内存中，这些内存只有在MySQL重启时才会释放。

我的建议很简单：应该启用Performance Schema，按需动态地启用插桩和消费者表，通过它们提供的数据可以解决可能存在的任何问题——查询性能、锁定、磁盘I/O、错误等。充分利用sys schema是解决常见问题的捷径。这样做将为你提供一种可以直接从MySQL中测量性能的方法。

MYSQL优化
1.硬件
innodb使用内存作为缓存,CPU瓶颈,硬盘空间,垃圾清理
连接数,innodb缓冲池
线程缓存
2.数据类型 varchar char
最小数据类型
smallint int bigint
datetime timestamp
ip存储 varchar15 实际是32位无符号数字
innodb复制行到缓冲区涉及行格式转换,太多列导致资源占用多.
枚举
null使用导致索引规则复杂

小结
好的schema设计是非常普遍的，但是MySQL有特殊的实现细节要考虑。简而言之，让事情尽可能小而简单是一个好主意。MySQL喜欢简单，需要使用数据库的人也喜欢简单。请记住以下指导原则：

● 尽量避免在设计中出现极端情况，例如，强制执行非常复杂的查询或者包含很多列的表设计（很多的意思是介于有点多和非常多之间）。

● 使用小的、简单的、适当的数据类型，并避免使用NULL，除非确实是对真实数据进行建模的正确方法。

● 尝试使用相同的数据类型来存储相似或相关的值，尤其是在联接条件中使用这些值时。

● 注意可变长度字符串，它可能会导致临时表和排序的全长内存分配不乐观。

● 如果可能的话，尝试使用整数作为标识符。

● 避免使用一些传统的MySQL技巧，例如，指定浮点数的精度或整数的显示宽度。

● 小心使用ENUM和SET类型。它们很方便，但也可能被滥用，有时还很棘手。另外最好避免使用BIT类型。

数据库设计是一门科学。如果你非常关注数据库设计，可考虑使用专用的源材料。[8]

还请记住，你的schema将随着业务需求和用户数据而发展，这意味着拥有一个强大的软件生命周期来管理schema更改是使这种发展在组织中安全且可扩展的关键部分。

[1] 请记住，字符串长度定义的不是字节数，是字符数。多字节字符集可能需要多个字节来存储1个字符。

[2] 如果需要在检索后保持值不变，请小心使用BINARY类型，MySQL会使用\0将其填充到需要的长度。

[3] 这里显示的速度是相对的，因为CPU、内存和其他硬件的速度会随着时间的变化而变化。

[4] TIMESTAMP的行为规则很复杂，并且在不同的MySQL版本中会发生变化，因此你应该验证数据库的行为是否符合需要。在对TIMESTAMP列进行更改后，通常最好检查SHOW CREATE TABLE命令的输出。

[5] 如果使用InnoDB存储引擎，除非数据类型完全匹配，否则可能无法创建外键，对应的错误消息是“ERROR 1005（HY000）：Can't create table”。这个信息可能让人困惑，具体取决于上下文，MySQL邮件列表中经常会出现相关问题。（奇怪的是，可以在不同长度的VARCHAR列之间创建外键。）

[6] 另一方面，对于一些有很多写入的非常大的表，这种伪随机值实际上可以帮助消除“热点”。

[7] 更多信息请参阅MySQL文档（参见链接29）。

[8] 要进行深入学习，请参阅Michael J.Hernandez（Pearson）的Database Design for Mere Mortals。