第七章 Mysql高性能学习笔记02.pdf

Mysql高性能学习笔记2 刘岩 suhuanzheng7784877@163.com Blog: 1.前言 高性能Mysql 中的第二章-基准测试和第三章- 服务器性能剖析是需要全局考虑的问题，不同的应用场景，基准测试的方式和 输入数据是不太一样的。所以我们后续再讨论这两个问题，先放过去，直接进 行优化schema和数据类型的这一话题。 2.优化数据类型 优化数据类型，基本上是用在建表和修改表的场景上，整个优化数据类型 这一话题说下来，基本上都是集中于：对于DB数据的高效存储和高效查询。在 原生的Mysql 中，数据类型大体上分为以下几种：整数类型、实数类型、字符串 类型、日期时间类型、位数类型、特殊类型。 优化数据类型基本上参照以下几个原则： 1）：使用小类型的数据类型，能用int 的别用long 。小数据类型在磁盘寻址 的时候占用更少的资源，也减少了CPU 的运算时间，这样在iowait 的时候就不会 因为大字段而消耗过多资源。 2 ）：简单类型优先，这个就需要结合应用层语言的知识来阐述了，比如Jav a 中的int类型和Integer类型，哪个更耗资源，答案肯定是Integer ，在《Java代码 优化》中就曾经提出过，使用原始类型表述属性值。在Mysql也是如此，能使用 最简单的类型代表字段的，尽量使用简单类型。这样更贴近于CPU原生支持的 计算类型。比如使用整型存储时间戳；用整型存储IP地址；用整型存储货币浮 点，在应用层，再用乘除法换算小数点的精度。 3 ）：不是必要时刻，不要使用NULL ，让所有字段哪怕是有默认的值，也 要非空。对于优化索引，如果字段是NULL ，无法对其NULL进行索引排列。不 过InnoDB对于NULL是做了特殊的bit位存储。 1 3.整型类型 Tinyint （8位） 范围：无符号（0~256 ）、有符号（-128~127 ） 场景：一般用于存储数字字典，常量表的id，因为数据量十分有限，又是常 量表，所以可以用它存储 Smallint （16位） 范围：无符号（0~65536 ）、有符号（-32768~32767 ） 场景：Tinyint 的替代品，若常量表数据比较多，比如中国的省-市- 自治区- 区县-村镇，到这个范围下，基本够用了。中国有65536个村镇（区县）吗？ Mediumint （24位） 范围：无符号（0）、有符号（-8388608~8388607 ） 场景：1000w以内的数据，这个若是日志表，又是在一段时间内数据量可控 ，定时清理，Mediumint不失为是轻量级的int 的一种id选择。 Int （32位）：大多数场景，一般Java 的int也支持不了这么长的整数位！ 范围：无符号（0~4294967296 ）、有符号（-2147483648~2147483647 ） 场景：大多数的自增id场景，基本够用了。无符号40多亿数据，一般的中小 型，互联网，基本够用。 Bigint （64位）范围：天文数字，在Java 中必须特殊处理该数字类型—— BigDecimal进行处理。 范围：无符号（0~18446744073709551616 ）、有符号（- 922337203685478~922337203685477 ）。 2 场景：使用关系型数据库存储海量数据的id 。千万大一位是亿，亿大一位是 兆，兆在大一位是什么？？？？不过数据量在这个范围，很难想象还用RDBMS 进行管理。 有符号与无符号的最大区别就是是否支持负数。Unsigned一旦被选择上了， 表示不允许负数，也就是存储无符号数。一般情况下无符号int类型的字段几乎 可以满足系统要求了，就算是自增id类型。40多亿的mysql数据量也已经比较不 小了。日交易量记录上千万比记录，一个月也就区区3亿记录。如果大于这个数 量级的数据，又是实时数据，应该考虑分表分库。或者借助NoSQL ，将数据量 散列拆分开。扯远了，这里就是告诉大家，数值类型字段支持的范围。 4.实数类型 其实基本上也就是指含