-
性能不佳是单条查询问题还是服务器问题？
- 使用show global status
- 使用show processlist
- 使用慢查询
第四章 表结构与数据类型
- 选择优化的数据类型
- 更小的通常最好，如果无法确定哪个数据类型是最好的，就选择你认为不会超过范围的最小类型。
- 简单就好，整型比字符型操作代价更低，因为字符集和校对规则（排序规则）使字符比较比整型比较更复杂。
- 尽量避免null，当可为null的列被索引时，每个索引记录需要一个额外的字节，在myisam里甚至还可能导致固定大小的索引。
- 整数类型
- TINYINT/SMALLINT/MEDIUMINT/INT/BIGINT 分别使用8,16,24,32,64位存储空间，存储值的范围是：-2(N-1)~2(N-1)-1，其中N是存储空间的位数。
- 存储值的范围是指数值大小，不是字符数。
- tinyint(2)里面的2是指显示宽度并不是限制值的大小，如下显示，并且指定列为zerofill(填充零)时，方可显示出来，甚至有的时候只是在MySQL命令行下面显示而已。
- tinyint(1)和tinyint(20)对于存储和计算来说其实是一样的。
| id | value |
|---|---|
| 1001 | 02 |
- decimal只是一种存储格式，在计算中decimal会转换成为double类型。float使用4个字节存储，double占用8个字节。
- 因为需要额外的空间和计算开销，所以应该尽量只在对小数进行精确计算时才使用decimal————例如存储财务数据。但在数据量比较大的时候，可以考虑使用bigint代替decimal，将需要存储的货币单位根据小数的位数乘以相应的倍数即可。假设要存储财务数据精确到万分之一分，则可以把所有金额乘以一百万，然后将结果存储在bigint里，这样可以同时避免浮点存储计算不精确和decimal精确计算代价高的问题。
- 因为CPU不支持对decimal的直接计算，所以在MySQL5.0以及更高的版本中，MySQL服务器自身实现了decimal的高精度计算，相对而言，cpu直接支持原生浮点计算，所以浮点运算明显更快。
- MySQL浮点计算精度丢失问题参考
- 字符串类型
- 数据存储的最小信息单元是字节B，数据传输的最小单位是位（一位就是0或者1）
- VARCHAR(2)小括号里面的就是值的宽度限制，2就表示只能存储2个字符，比如0./12/你好/-1，存储不了0.0/233/-10/你好吗
- VARCHAR需要使用1或2个额外字节记录字符串长度：如果列的最大长度小于或者等于255字节，则只使用1个字节表示，否则使用2个字节。假设采用Latin1字符集，一个VARCHAR(10)的列需要11个字节的存储空间。VARCHAR的列则需要1002个字节，因为需要2个字节存储长度信息。
- VARCHAR适合的：字符串列的最大长度比平均长度大很多；列的更新很少，所以碎片不是问题；使用了像UTF-8这样复杂的字符集，每个字符都使用不同的字节数进行存储。
- UTF-8的字符集：它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。阅读
- 当存储CHAR值MySQL会删除所有末尾的空格。
- CHAR适合存储很短的字符串，或者所有值都接近同一个长度（MD5），对于经常变更的数据，CHAR也比VARCHAR更好，因为定长的CHAR类型不容易产生碎片，对于非常短的列，CHAR比VARCHAR在存储空间上也更有效率，例如用CHAR(1)来存储只有Y和N的值，如果采用单字节字符集只需要一个字节，但是VARCHAR(1)却需要两个字节，因为还有一个记录长度的额外字节。
- 当存储CHAR值时，MySQL会删除所有的末尾空格，在MySQL4.1版本和更老版本中，VARCHAR和CHAR的处理逻辑是一样的。
存在的疑惑
- UPDATE时可能使行变得比原来更长，这就导致需要做额外的工作，如果一个行占用的空间增长，并且在业内没有更多的空间存储，在这种情况下，不同的存储引擎的处理方式是不一样的。例如：myisam会将行拆成不同的片段存储，innodb则需要分裂页来使行可以放进页内。
- 关于页的概念，可以查看阅读
- 使用VARCHAR(5)和VARCHAR(200)存储’hello’的空间开销是一样的，那么使用更短的列有什么优势吗？
事实证明有很大的优势，更长的列会消耗更多的内存，因为MySQL通常会分配固定大小的内存块来保存内部值。尤其是使用内存临时表进行排序或操作时会特别糟糕。在利用磁盘临时表进行排序时也同样糟糕。所以最好的策略是只分配真正需要的空间。