高性能MySQL

从安全稳妥的角度考虑，建议还是优先选择 DATETIME 类型，虽然相比 TIMESTAMP 会牺牲一点性能，但是 TIMESTAMP 的时间范围是硬伤。

MySQL 是可以自定义临时变量的，而临时变量在做查询优化和静态查询分析时十分有用。而实际上很少有人记得 MySQL 的自定义变量。

对于程序员来说，最为难能可贵的职业素养之一就是回顾。去回顾自己写过的代码、设计过的数据表，然后再重新整理思路，优化和重构部分代码。

设计统计数据表，关键的核心在于业务类型。对于更新频率低、数据量小的表使用实时同步或者直接 SUM 求和问题都不大。而对于大数据表，高频率的更新的情况，则可以使用独立的统计表。

范式和反范式数据库设计本身的理念是值得参考的，我们可以更清楚地知道数据库该如何设计。在实际开发过程中，需要根据实际业务来决定主要遵循那种方式。

在实际设计数据表的过程中，除了需要考虑每个字段的数据类型之外，还需要考虑存储空间大小。对于常用的一些字段，如时间、标题、备注等，最好是内部形成一定的规范，大家遵照规范执行，增加校验能够避免很多问题

为 id 列选择一个好的数据类型非常重要，id 列会经常用于做比较，以及用于查找其他列。而且，id 也经常用于外键。因此，id 列的数据类型不仅仅关系自身数据表，也关系到与之关联的数据表。

枚举因为使用1-2个字节的整型存储字段值，因此存储空间会更小。但实际返回的结果需要从对应表找，会有一定的性能损耗。在实际应用中，还有一种更为实际的做法，就是将枚举值当做整型存储到数据表。

在实际数据表设计中，大多数情况下会选择使用 VARCHAR，但 VARCHAR 需要额外的1-2个字节存储字符串长度。对于固定长度、长度很短或长度变化很小的字符类型，推荐使用 CHAR 类存储。

MySQL 中有多种类型存储数值，需要从存储空间大小、数值范围、精确度、计算性能等多方面考虑。总而言之，要依据业务考虑如何选择存储类型。

MySQL支持大量的数据类型，选择正确的类型对性能十分关键。本篇介绍了MySQL 的数据类型选择原则，可以根据这些基本的原则确定数据表字段的具体数据类型。

全文检索需要特殊的查询语法。有没有索引都可以进行全文检索，但是存在索引时会提高匹配的速度。全文检索的索引通过特殊的结构存储以便于找到文档中包含搜索关键字对应的内容。本篇介绍全文索引的使用。

事件由于没有了 SQL 连接建立的过程，因此效率会更高，而且开销不大。适用于需要周期性运行的 SQL 脚本任务，例如数据表优化、生成统计报表数据等等。

触发器在有限的场合能够发挥其优势，比如统计数据、数据表变更日志等。但是也会有缺陷，大数据量的更新逐行触发，会降低效率。还有就是，MyISAM 引擎无法保障原子性。因此，要根据应用场景是否要使用触发器。

对于一些稳定的业务，如果是因为与数据库服务器之间的网络请求过多或占用了大量的网络带宽，则可以考虑使用存储过程来优化性能，提高响应速度。但是，存储过程务必反复验证，避免出现意向不到的错误。

早期的数据库表结构设计中，往往会把一张表引用另外一张表的字段（通常是 id）作为外键，借助 MySQL 自动维护外键，确实能够省掉很多开发工作，外键实际的性能不高，很多数据表设计规范明确禁止使用外键。

视图实际是一个自身不存储数据的虚拟数据表。实际这个虚拟表的数据来自于访问视图的 SQL 查询的结果。本篇介绍了视图的实现机制和特点。

分区引入了的新的方式来优化查询（当然也会有一些坑）。最大的特性是优化器可以使用分区函数过滤掉无关的分区。这个特性就像是一个粗粒度的索引，使得查询时可以访问更少的数据。

分区能够解决大数据表的查询性能问题，但是，分期也不是完美的解决方案，了解分区的策略，可能产生的问题有助于避免掉进分区的缺陷产生的坑或降低分区对性能的影响。

当数据表过大时，通过普通的查询优化技巧已经无法大幅度提升性能，此时往往需要进行分区分表优化。分区其实是将一张逻辑上统一的表在物理上划分成了多张表。