sql优化 分表字段 一般有用 看4 速

 

　　16. 垂直分割

“垂直分割”是一种把数据库中的表按列变成几张表的方法，这样可以降

低表的复杂度和字段的数目，从而达到优化的目的。(以前，在银行做过项目，

见过一张表有 100 多个字段，很恐怖)

示例一：在 Users 表中有一个字段是家庭地址，这个字段是可选字段，相

比起，而且你在数据库操作的时候除了个人信息外，你并不需要经常读取或是

改写这个字段。那么，为什么不把他放到另外一张表中呢? 这样会让你的表有

更好的性能，大家想想是不是，大量的时候，我对于用户表来说，只有用户

ID，用户名，口令，用户角色等会被经常使用。小一点的表总是会有好的性

能。

示例二： 你有一个叫 “last_login” 的字段，它会在每次用户登录时被

更新。但是，每次更新时会导致该表的查询缓存被清空。所以，你可以把这个

字段放到另一个表中，这样就不会影响你对用户 ID，用户名，用户角色的不停

地读取了，因为查询缓存会帮你增加很多性能。

另外，你需要注意的是，这些被分出去的字段所形成的表，你不会经常性

地去 Join 他们，不然的话，这样的性能会比不分割时还要差，而且，会是极数

级的下降。　　

17. 拆分大的 DELETE 或 INSERT 语句

如果你需要在一个在线的网站上去执行一个大的 DELETE 或 INSERT 查询，

你需要非常小心，要避免你的操作让你的整个网站停止相应。因为这两个操作

是会锁表的，表一锁住了，别的操作都进不来了。

Apache 会有很多的子进程或线程。所以，其工作起来相当有效率，而我们

的服务器也不希望有太多的子进程，线程和数据库链接，这是极大的占服务器

资源的事情，尤其是内存。

如果你把你的表锁上一段时间，比如 30 秒钟，那么对于一个有很高访问量

的站点来说，这 30 秒所积累的访问进程/线程，数据库链接，打开的文件数，

可能不仅仅会让你泊 WEB 服务 Crash，还可能会让你的整台服务器马上掛了。

所以，如果你有一个大的处理，你定你一定把其拆分，使用 LIMIT 条件是

一个好的方法。下面是一个示例：

　　18. 越小的列会越快对于大多数的数据库引擎来说，硬盘操作可能是最重大的瓶颈。所以，把

你的数据变得紧凑会对这种情况非常有帮助，因为这减少了对硬盘的访问。

参看 MySQL 的文档 Storage Requirements 查看所有的数据类型。

如果一个表只会有几列罢了(比如说字典表，配置表)，那么，我们就没有

理由使用 INT 来做主键，使用 MEDIUMINT, SMALLINT 或是更小的 TINYINT 会更

经济一些。如果你不需要记录时间，使用 DATE 要比 DATETIME 好得多。

当然，你也需要留够足够的扩展空间，不然，你日后来干这个事，你会死

的很难看，参看 Slashdot 的例子(2009 年 11 月 06 日)，一个简单的 ALTER

TABLE 语句花了 3 个多小时，因为里面有一千六百万条数据。

　　19. 选择正确的存储引擎

在 MySQL 中有两个存储引擎 MyISAM 和 InnoDB，每个引擎都有利有弊。酷

壳以前文章《MySQL: InnoDB 还是 MyISAM?》讨论和这个事情。

MyISAM 适合于一些需要大量查询的应用，但其对于有大量写操作并不是很

好。甚至你只是需要 update 一个字段，整个表都会被锁起来，而别的进程，就

算是读进程都无法操作直到读操作完成。另外，MyISAM 对于 SELECT COUNT(*)

这类的计算是超快无比的。

InnoDB 的趋势会是一个非常复杂的存储引擎，对于一些小的应用，它会比

MyISAM 还慢。他是它支持“行锁” ，于是在写操作比较多的时候，会更优秀。

并且，他还支持更多的高级应用，比如：事务。

下面是 MySQL 的手册target=”_blank”MyISAM Storage Engine

InnoDB Storage Engine

　　20. 使用一个对象关系映射器(Object Relational Mapper)

 

链接”之前，你需要好好地考虑一下你的整个系统的架构。