对于大多数的数据库引擎来说,硬盘操作可能是最重大的瓶颈。所以,把你的数据变得紧凑会对这种情况非常有帮助,因为这减少了对硬盘的访问。 
如果一个表只会有几列罢了(比如说字典表,配置表),那么,我们就没有理由使用 INT 来做主键,使用 MEDIUMINT, SMALLINT 或是更小的 TINYINT 会更经济一些。如果你不需要记录时间,使用 DATE 要比 DATETIME 好得多。 
当然,你也需要留够足够的扩展空间,不然,你日后来干这个事,你会死的很难看,参看Slashdot的例子(2009年11月06 日),一个简单的ALTER TABLE语句花了3个多小时,因为里面有一千六百万条数据。

表结构优化

一、数据类型选择
     数据库操作中最为耗时的操作就是 IO 处理,大部分数据库操作 90% 以上的时间都花在了 IO 读写上面。所以尽可能减少 IO 读写量,可以在很大程度上提高数据库操作的性能。

我们无法改变数据库中需要存储的数据,但是我们可以在这些数据的存储方式方面花一些心思。下面的这些关于字段类型的优化建议主要适用于记录条数较多,数据量较大的场景,因为精细化的数据类型设置可能带来维护成本的提高,过度优化也可能会带来其他的问题:

1.数字类型:非万不得已不要使用DOUBLE,不仅仅只是存储长度的问题,同时还会存在精确性的问题。同样,固定精度的小数,也不建议使用DECIMAL,建议乘以固定倍数转换成整数存储,可以大大节省存储空间,且不会带来任何附加维护成本。对于整数的存储,在数据量较大的情况下,建议区分开 TINYINT / INT / BIGINT 的选择,因为三者所占用的存储空间也有很大的差别,能确定不会使用负数的字段,建议添加unsigned定义。当然,如果数据量较小的数据库,也可以不用严格区分三个整数类型。
2.字符类型:非万不得已不要使用 TEXT 数据类型,其处理方式决定了他的性能要低于char或者是varchar类型的处理。定长字段,建议使用 CHAR 类型,不定长字段尽量使用 VARCHAR,且仅仅设定适当的最大长度,而不是非常随意的给一个很大的最大长度限定,因为不同的长度范围,MySQL也会有不一样的存储处理。
3.时间类型:尽量使用TIMESTAMP类型,因为其存储空间只需要 DATETIME 类型的一半。对于只需要精确到某一天的数据类型,建议使用DATE类型,因为他的存储空间只需要3个字节,比TIMESTAMP还少。不建议通过INT类型类存储一个unix timestamp 的值,因为这太不直观,会给维护带来不必要的麻烦,同时还不会带来任何好处。
4.ENUM & SET:对于状态字段,可以尝试使用 ENUM 来存放,因为可以极大的降低存储空间,而且即使需要增加新的类型,只要增加于末尾,修改结构也不需要重建表数据。如果是存放可预先定义的属性数据呢?可以尝试使用SET类型,即使存在多种属性,同样可以游刃有余,同时还可以节省不小的存储空间。
5.LOB类型:强烈反对在数据库中存放 LOB 类型数据,虽然数据库提供了这样的功能,但这不是他所擅长的,我们更应该让合适的工具做他擅长的事情,才能将其发挥到极致。在数据库中存储 LOB 数据就像让一个多年前在学校学过一点Java的营销专业人员来写 Java 代码一样。
二、字符编码
     字符集直接决定了数据在MySQL中的存储编码方式,由于同样的内容使用不同字符集表示所占用的空间大小会有较大的差异,所以通过使用合适的字符集,可以帮助我们尽可能减少数据量,进而减少IO操作次数。

1.纯拉丁字符能表示的内容,没必要选择 latin1 之外的其他字符编码,因为这会节省大量的存储空间
2.如果我们可以确定不需要存放多种语言,就没必要非得使用UTF8或者其他UNICODE字符类型,这回造成大量的存储空间浪费
3.MySQL的数据类型可以精确到字段,所以当我们需要大型数据库中存放多字节数据的时候,可以通过对不同表不同字段使用不同的数据类型来较大程度减小数据存储量,进而降低 IO 操作次数并提高缓存命中率

三、适当拆分

     有些时候,我们可能会希望将一个完整的对象对应于一张数据库表,这对于应用程序开发来说是很有好的,但是有些时候可能会在性能上带来较大的问题。

当我们的表中存在类似于 TEXT 或者是很大的 VARCHAR类型的大字段的时候,如果我们大部分访问这张表的时候都不需要这个字段,我们就该义无反顾的将其拆分到另外的独立表中,以减少常用数据所占用的存储空间。这样做的一个明显好处就是每个数据块中可以存储的数据条数可以大大增加,既减少物理 IO 次数,也能大大提高内存中的缓存命中率。

上面几点的优化都是为了减少每条记录的存储空间大小,让每个数据库中能够存储更多的记录条数,以达到减少 IO 操作次数,提高缓存命中率。下面这个优化建议可能很多开发人员都会觉得不太理解,因为这是典型的反范式设计,而且也和上面的几点优化建议的目标相违背。

四、适度冗余

为什么我们要冗余?这不是增加了每条数据的大小,减少了每个数据块可存放记录条数吗?
确实,这样做是会增大每条记录的大小,降低每条记录中可存放数据的条数,但是在有些场景下我们仍然还是不得不这样做:

被频繁引用且只能通过 Join 2张(或者更多)大表的方式才能得到的独立小字段
这样的场景由于每次Join仅仅只是为了取得某个小字段的值,Join到的记录又大,会造成大量不必要的 IO,完全可以通过空间换取时间的方式来优化。不过,冗余的同时需要确保数据的一致性不会遭到破坏,确保更新的同时冗余字段也被更新

五、尽量使用 NOT NULL

NULL 类型比较特殊,SQL 难优化。虽然 MySQL NULL类型和 Oracle 的NULL 有差异,会进入索引中,但如果是一个组合索引,那么这个NULL 类型的字段会极大影响整个索引的效率。此外,NULL 在索引中的处理也是特殊的,也会占用额外的存放空间。
很多人觉得 NULL 会节省一些空间,所以尽量让NULL来达到节省IO的目的,但是大部分时候这会适得其反,虽然空间上可能确实有一定节省,倒是带来了很多其他的优化问题,不但没有将IO量省下来,反而加大了SQL的IO量。所以尽量确保 DEFAULT 值不是 NULL,也是一个很好的表结构设计优化习惯。

六、分离冷热数据

将大字段、访问频率低的字段拆分到单独的表中存储,分离冷热数据,有利于有效利用缓存,防止读入无用的冷数据,较少磁盘IO,同时保证热数据常驻内存提高缓存命中率。

六、避免大表的DDL操作

MYSQL的新增和修改列的操作相当于重建表,表设计要一步到位,尽量避免大表的DDL操作。 (TIPS:可以预定义一些列留作将来业务扩展,如:当前只需要10个字段,考虑到未来发展,可以预留10个字段,表上总共创建20个字段)

七、定期分析表和检查表

分析表的语法:ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tb1_name[, tbl_name]...

以上语句用于分析和存储表的关键字分布,分析的结果将可以使得系统得到准确的统计信息,使得SQL能够生成正确的执行计划。如果用户感觉实际执行计 划并不是预期的执行计划,执行一次分析表可能会解决问题。在分析期间,使用一个读取锁定对表进行锁定。这对于MyISAM,DBD和InnoDB表有作 用。

例如分析一个数据表:analyze table table_name
检查表的语法:CHECK TABLE tb1_name[,tbl_name]...[option]...option = {QUICK | FAST | MEDIUM | EXTENDED | CHANGED}

检查表的作用是检查一个或多个表是否有错误,CHECK TABLE 对MyISAM 和 InnoDB表有作用,对于MyISAM表,关键字统计数据被更新

CHECK TABLE 也可以检查视图是否有错误,比如在视图定义中被引用的表不存在。

八、定期优化表

定期分析表
 
ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name]
 
本语句用于分析和存储表的关键字分布。在分析期间,使用一个读取锁定对表进行锁定。这对于MyISAM, BDB和InnoDB表有作用。对于MyISAM表,本语句与使用myisamchk -a相当。
 
MySQL使用已存储的关键字分布来决定,当您对除常数以外的对象执行联合时,表按什么顺序进行联合。 
mysql> analyze table a;
+--------+---------+----------+-----------------------------+
| Table  | Op      | Msg_type | Msg_text                    |
+--------+---------+----------+-----------------------------+
| test.a | analyze | status   | Table is already up to date | 
+--------+---------+----------+-----------------------------+
1 row in set (0.00 sec)
 
定期检查表
 
CHECK TABLE tbl_name [, tbl_name]  [option] 
 
option = {QUICK | FAST | MEDIUM | EXTENDED | CHANGED}
 
检查一个或多个表是否有错误。CHECK TABLE对MyISAM和InnoDB表有作用。对于MyISAM表,关键字统计数据被更新。
mysql> check table a;
+--------+-------+----------+----------+
| Table  | Op    | Msg_type | Msg_text |
+--------+-------+----------+----------+
| test.a | check | status   | OK       | 
+--------+-------+----------+----------+
1 row in set (0.00 sec)
 
CHECK TABLE也可以检查视图是否有错误,比如在视图定义中被引用的表已不存在。
我们为上面的表a创建一个视图 
mysql> create view a_view as select * from a;
Query OK, 0 rows affected (0.02 sec)
 
然后CHECK一下该视图,发现没有问题
mysql> check table a_view;
+-------------+-------+----------+----------+
| Table       | Op    | Msg_type | Msg_text |
+-------------+-------+----------+----------+
| test.a_view | check | status   | OK       | 
+-------------+-------+----------+----------+
1 row in set (0.00 sec)
 
现在删掉视图依赖的表
mysql> drop table a;
Query OK, 0 rows affected (0.01 sec)
 
再CHECK一下刚才的视图,发现报错了
mysql> check table a_view\G;
*************************** 1. row ***************************
   Table: test.a_view
      Op: check
Msg_type: Error
Msg_text: Table 'test.a' doesn't exist
*************************** 2. row ***************************
   Table: test.a_view
      Op: check
Msg_type: Error
Msg_text: View 'test.a_view' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them
*************************** 3. row ***************************
   Table: test.a_view
      Op: check
Msg_type: error
Msg_text: Corrupt
3 rows in set (0.00 sec)
 
ERROR: 
No query specified
 
定期优化表
 
OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] 
 
如果您已经删除了表的一大部分,或者如果您已经对含有可变长度行的表(含有VARCHAR, BLOB或TEXT列的表)进行了很多更改,则应使用OPTIMIZE TABLE。被删除的记录被保持在链接清单中,后续的INSERT操作会重新使用旧的记录位置。您可以使用OPTIMIZE TABLE来重新利用未使用的空间,并整理数据文件的碎片。
在多数的设置中,您根本不需要运行OPTIMIZE TABLE。即使您对可变长度的行进行了大量的更新,您也不需要经常运行,每周一次或每月一次即可,只对特定的表运行。
OPTIMIZE TABLE只对MyISAM, BDB和InnoDB表起作用。
对于MyISAM表,OPTIMIZE TABLE按如下方式操作:
如果表已经删除或分解了行,则修复表。
如果未对索引页进行分类,则进行分类。
如果表的统计数据没有更新(并且通过对索引进行分类不能实现修复),则进行更新。 
mysql> OPTIMIZE table a;
+--------+----------+----------+-----------------------------+
| Table  | Op       | Msg_type | Msg_text                    |
+--------+----------+----------+-----------------------------+
| test.a | optimize | status   | Table is already up to date | 
+--------+----------+----------+-----------------------------+
1 row in set (0.00 sec)
 
****
需要注意的是无论是ANALYZE,CHECK还是OPTIMIZE在执行期间将对表进行锁定,因此请注意这些操作要在数据库不繁忙的时候执行
****

表结构优化可以使用Procedure Analyse()帮助分析。详细见《分析诊断工具之五:Procedure Analyse优化表结构

mysql实战优化之三:表优化的更多相关文章

  1. MySQL千万级大表优化解决方案

    MySQL千万级大表优化解决方案 非原创,纯属记录一下. 背景 无意间看到了这篇文章,作者写的很棒,于是乎,本人自私一把,把干货保存下来.:-) 问题概述 使用阿里云rds for MySQL数据库( ...

  2. Mysql千万级大表优化

    Mysql的单张表的最大数据存储量尚没有定论,一般情况下mysql单表记录超过千万以后性能会变得很差.因此,总结一些相关的Mysql千万级大表的优化策略. 1.优化sql以及索引 1.1优化sql 1 ...

  3. MySQL 上亿大表优化实践

    目录 背景 分析 select xxx_record语句 delete xxx_record语句 测试 实施 索引优化后 delete大表优化为小批量删除 总结 背景 XX实例(一主一从)xxx告警中 ...

  4. Mysql千万级大表优化策略

    1.优化sql以及索引 1.1优化sql 1.有索引但未被用到的情况(不建议) (1)避免like的参数以通配符开头时 尽量避免Like的参数以通配符开头,否则数据库引擎会放弃使用索引而进行全表扫描. ...

  5. MySQL的索引单表优化案例分析

    建表 建立本次优化案例中所需的数据库及数据表 CREATE DATABASE db0206; USE db0206; CREATE TABLE `db0206`.`article`( `id` INT ...

  6. 【优化】MySQL千万级大表优化解决方案

    问题概述 使用阿里云rds for MySQL数据库(就是MySQL5.6版本),有个用户上网记录表6个月的数据量近2000万,保留最近一年的数据量达到4000万,查询速度极慢,日常卡死.严重影响业务 ...

  7. 数据库的优化(表优化和sql语句优化)

    在这里主要是分为表设计优化和sql语句优化两方面来实现. 首先的是表设计优化: 1.数据行的长度不要超过8020字节.如果是超过这个长度的话这条数据会占用两行,减低查询的效率. 2.能用数字类型就不要 ...

  8. 【SQL优化】MySQL官网中可优化的层次结构

    正如上一篇中我翻译的那篇文章,关于MySQL数据库优化的宏观介绍,了解到了从大体上来讲,优化MySQL可以从3个角度来讲.那么这一篇文章,则从一个个优化点出发,统计出究竟有多少个地方我们可以来优化My ...

  9. 详解MySQL大表优化方案( 转)

    当MySQL单表记录数过大时,增删改查性能都会急剧下降,可以参考以下步骤来优化: 单表优化 除非单表数据未来会一直不断上涨,否则不要一开始就考虑拆分,拆分会带来逻辑.部署.运维的各种复杂度,一般以整型 ...

  10. [MySQL] 两个优化数据库表的简单方法--18.3

    这里介绍两个简单的优化MySQL数据库表的方法 一.定期分析表和检查表 1.分析表语法如下: alalyze [local|no_write_to_binlog] table table_name1[ ...

随机推荐

  1. Selenium with Python 010 - unittest 框架(又称PyUnit 框架)

    unittest进行python代码单元测试 calculator.py--被测试类 #!/usr/bin/env python # -*- coding: utf-8 -*- # 将要被测试的类 c ...

  2. mysql-in关键字,分组查询,分页查询

    1. in关键字,组查询 # 使用or来查询的化,不方便而且参数一多比较傻 select * from users where id=1 or id=2 or id=4; select * from ...

  3. GDB和Core Dump使用笔记

    一.GNU C编译器(即GCC) GCC使用 1 .gcc -g hello.c -o hello   编译生成可执行文件 2.gdb hello                     启动GDB ...

  4. OC-常见归档总结

    /*****  该文一共总结了以下六种文件操作   1.NSKeyedArchiver. 2.对类对象进行归档 <NSCoder>协议 3.文件管理类 NSFileManger  4.对文 ...

  5. 谈一下思考,关于mybatis中<foreach collection="list">中list得来的原因 没看到官方说明

    <foreach> 是在sql语句中进行多个id查询 时用到的,因为mybatis代替jdbc和hibernate, 使用 在xml文件中编写sql语句,这是一个标签文件.然后在 dao层 ...

  6. Mongodb 补充

    1 mongodb 概述 启动mongo 1 数据库操作 没有数据的 集合 和 数据库不会显示 db 查看当前的数据库名称: 所有物理上存在的数据库 db.stats() 查看当前的数据库信息: sh ...

  7. Dojo仪表盘

    Dojo提供了非常好的仪表盘显示,效果如下: <!DOCTYPE html> <html> <head> <title>Dojo仪表盘</titl ...

  8. Could not publish to the server.Please assign JRE to the server

    1.错误描述 2.错误原因 由错误提示可知,是Tomcat未绑定JRE,导致报错 3.解决办法 (1)删除新建Tomcat (2)重新新建一个Tomcat,配置好Tomcat路径和JRE路径

  9. js将json数据动态生成表格

    今天开发中遇到需要展示动态数据的问题, 具体要求是后端传来的json字符串,要在前端页面以table表格的形式展示, 其实没啥难的,就是拼接table标签,纯属体力活,于是自己写了个呆萌,保存起来,以 ...

  10. VS for Mac安装之路

    首先说四个字:水土不服 作为宇宙最强IDE,从开始编程就一直用的Visual Studio,最近新买了Mac,发现微软发布了VS for Mac,于是打算安装一个试试,怎奈,微软的产品在别家水土不服, ...