MySQL5.1性能优化方案

1、 11/11MySQL5.1性能优化方案 MySQL5.1性能优化方案 1.平台数据库 1.1. 操作系统 Red Hat Enterprise Linux Server release 5.4 (Tikanga) ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped 32位Linux服务器，单独作为MySQL服务器使用。 1.2. MySQL 系统使用的

2、是MySQL5.1，最新的MySQL5.5较之老版本有了大幅改进。主要体现在以下几个方面： 1）默认存储引擎更改为InnoDB InnoDB作为成熟、高效的事务引擎，目前已经广泛使用，但MySQL5.1之前的版本默认引擎均为MyISAM，此次MySQL5.5终于将默认数据库存储引擎改为InnoDB，并且引进了Innodb plugin 1.0.7。此次更新对数据库的好处是显而易见的：InnoDB的数据恢复时间从过去的一个甚至几个小时，缩短到几分钟(InnoDB plugin 1.0.7，InnoDB plugin 1.1，恢复时采用红-黑树)。InnoDB Plugin 支持数据压缩存储，节约

3、存储，提高内存命中率，并且支持adaptive flush checkpoint, 可以在某些场合避免数据库出现突发性能瓶颈。 Multi Rollback Segments：原来InnoDB只有一个Segment，同时只支持1023的并发。现已扩充到128个Segments，从而解决了高并发的限制。 2）多核性能提升 Metadata Locking (MDL) Framework替换LOCK_open mutex (lock)，使得MySQL5.1及过去版本在多核心处理器上的性能瓶颈得到解决。 3）制功能(Replication)加强 过去的异步复制方式意味着极端情况下的数据风险，MySQ

4、L5.5将首次支持半同步(semi-sync replication)在MySQL的高可用方案中将产生更多更加可靠的方案。4）增强表分区功能 MySQL 5.5的分区更易于使用的增强功能，以及TRUNCATE PARTITION命令都可以为管理和维护数据库节省大量的时间，并且具有更加灵活高效的分区方式。 1.3. CPU 系统所用CPU是单个4核CPU。对于CPU密集的负载，MySQL通常从更快的CPU中获益，而不是更多CPU。MySQL5.1的架构对多CPU的扩展性不好，并且MySQL不能在多个CPU上并行地运行某个查询，因此在对于单个CPU进行密集的查询时，CPU速度限制了响应时间。为了实

5、现低延迟，即快速响应时间，需要快速的CPU，因为单个查询只能使用一个CPU。值得注意的是，MySQL5.5在多核心处理器上的性能有了很大的提升。另外，MySQL在64位架构上工作得更好，比32位架构更能有效地使用大量内存。 尽管本系统使用的是32位操作系统，CPU运行在32位模式下，但它仍支持64位计算。（cat /proc/cpuinfo | grep flags | grep lm | wc -l） 1.4. 磁盘空间 系统的磁盘空间目前没有压力。 1.5. 内存 内存总大小为4G，只供操作系统和数据库使用。 1.6. 数据库的表和文件 数据库addb共有339张表：其中InnoDB表30

6、3张，MyISAM表34张，MEMORY表2张。 InnoDB数据文件ibdata1大小为30138MB，一周后ibdata1大小为30234MB，MyISAM数据文件（包括表结构、索引及数据）总大小约为1642MB，一周后约为1639MB。可以看出，数据库的数据量较稳定，InnoDB数据文件增加了约106MB，总大小一周内没有大的变化。MyISAM表中，值得注意的是表terminalalarm_bak，该表总大小约为1623MB，占整个MyISAM表总大小比重近99%。 二进制日志单个文件大小为1GB，二进制日志文件总大小接近20GB。 1.7. 数据分布情况 服务器某时间点非精确值： 数据

7、量范围表数量（总共339张，其中分区表2张）1000万 100% （理想值 85%）。MySQL服务器实际上允许max_connections+1个客户端进行连接。额外的连接保留给具有SUPER权限的账户。通过为系统管理员而不是普通用户授予SUPER权限（普通用户不应具有该权限），系统管理员能够连接到服务器来诊断问题，即使已连接的无特权客户端数已达到最大值也同样。 本系统中设置的最大连接数是600，而响应的连接数是601，应适当增加Max_connections变量的值。 Open_files和Open_files_limit 如果Open_files的值与Open_files_limit的值

8、较为接近，那就应该增加Open_files_limit。 max_connections 和table_open_cache 与open_files_limit 的关系： max_1 = 10 + max_connections + table_cache * 2，该值为1122； max_2 = max_connections * 5，该值为3000； max_3 = max_os_open_files，该值为1024，表示操作系统单个进程最大允许打开文件句柄（文件描述符）。 open_files_limit 取三个值中的最大值，设置3000较合理，不需要调整。Select_full_joi

9、n 全联接是无索引联接，它真正影响性能，最好能避免全联接，即使是每分钟一次也较多，如果联接没有索引，则最好能优化查询和索引。 select_full_range_join 如果select_full_range_join的值过高，就说明运行了许多使用了范围查询联接表，有时大的范围查询也会比较慢，可以从中进行优化。 Select_range_check Select_range_check变量记录了在联接时，对每一行数据重新检查索引的查询计划的数量，它的性能开销很大，如果该值较高或正在增加，则说明一些查询没有找到好索引。 上述变量目前正常，如果发生明显变化，则结合慢查询日志跟踪全联接性能 较差的

10、查询。 Slow_launch_threads 该变量如果较大则说明某些因素正在延迟联接的新线程，服务器存在一些问题。它通常表示系统过载，导致操作系统不能给新创建的线程分配时间片。Table_locks_waited Table_locks_waited变量显示了有多少表被锁住了并且导致服务器级的锁等待，InnoDB的行级锁不会使该变量增加。如果该值较高并且正在增加，则说明存在严重的并发瓶颈，这时应该考虑使用InnoDB或另外使用行级锁的存储引擎，或者手动对大表进行分区，并优化查询，启用并发插入或对锁设置进行优化。 本系统该变量在半小时内变化幅度不超过3，不必调整。 2.MySQL优化策略 2

11、.1. 索引策略 索引是帮助MySQL高效获取数据的数据结构，它对于高性能非常关键，因此建立索引是现实中性能问题的首要原因。索引在数据越大的时候越重要。规模小，负载轻的数据库即使没有索引，也能有好的性能，但是当数据增加的时候，性能就会下降。 MySQL有多种类型类型的索引，它们各有自己的性能特点。索引是在存储引擎层实现的，而不是在服务器层，因此它们并不是标准化的，每个引擎的索引工作方式略有不同，并不是所有的引擎都支持所有类型的索引。即使多个引擎支持同样的索引，他们的实现方式也可能有所不同。MySQL索引类型的各自特点可以查阅相关资料去进一步了解。 即使已经了解了关于索引的知识，但也许还不知道如

12、何从实际的表开始。虽然通常情况下是检查系统中最常运行的查询，但往往性能瓶颈可能就出现在不那么经常进行的插入或更新操作，要避免在不知道什么查询会使用索引之前就创建它这种常见错误，并且要考虑是否所有的索引能形成一个优化的配置。 有时只从查询就可以知道需要什么索引，只要把它们加上就可以了。但是有时各种类型的查询，却不能找到适合他们的完美索引，这种情况就需要一些折中。为了找到最佳平衡，应该进行测试和剖析。 第一个要检查的就是响应时间，要考虑为任何耗时很长的查询创建索引，然后检查导致最大负载的查询，并且添加索引予以支持。如果系统正好碰到了内存、CPU或磁盘瓶颈，也要把他们考虑进去。例如，如果运行了很长的

13、聚合查询以生成汇总，那么磁盘会因为使用了支持GROUP BY查询的索引而得益。 通常情况下，都要试着扩展索引，而不是新增索引，维护一个多列索引要比维护多个单列索引容易，但不能过多否则就会有麻烦，使用太多这种列表也会造成优化器要计算的组合激增，并最终降低查询速度。如果不知道查询的分布，就尽可能使索引变得更有选择性，这样更有好处。即使已经创建了正确的索引，还需要维护表和索引以确保它们能很好的工作。 2.2. 查询性能优化 2.2.1优化数据访问 查询性能低下的最基本原因就是访问了太多数据。一些查询不可避免地要筛选大量数据，大部分性能欠佳的查询都可以用减少数据访问的方式进行修改。在分析性能较低的查询

14、的时候，查明应用程序是否正在获取超过需要的数据，即访问了过多的行或列，以及MySQL服务器是否分析了超过需要的行。 一些查询先向服务器请求不需要的数据，然后再丢掉它们。这给服务器造成了额外的负担，增加了网络开销，消耗了内存和CPU资源。 2.2.2重构查询 当优化有问题的查询时，并不意味着一定要从MySQL得到完全一样的结果，偶尔可以用完全等价的方式得到更好的性能。如果不同的查询能提供更高的效率，尽管得到的结果不同，也可以考虑重写查询。也许最终应用程序的代码也会和查询一起被改写。 MySQL Server 客户端 查询 缓存 解析器 解 析 树 预处理器 查询 优化器 查询 执行计划 查询执行

15、引擎 解 析 树 API调用 存储引擎 etc. MyISAM InnoDB SQL 结果 结果 数据 查询的执行路径 2.2.3复杂查询 一个重要的查询设计问题就是是否可以把一个复杂查询分解成多个简单的查询。大多数时候，都强调用用尽可能少的查询做尽可能多的事情。这种方式的积极意义在于它可以减少查询解析和优化的步骤，并且代码量较少。但是对于数据量较大的查询来说，通过分解查询可以得到更高的效率，同时也使程序更易于维护和扩展。可以使用分治法，让查询在本质上不变，但是每次只执行一小部分，以减少受影响的行数，清理陈旧数据也是一种很好的方式。 想得到高性能，最佳的方式就是了解MySQL如何优化和执行查询

16、，一旦理解了背后的机制，那么很多优化工作就简化为纯粹的推理，并且也可以理解查询优化过程中的逻辑性。 2.2.4分解联接 在较复杂实际应用中，可以采用“分解联接”把一个多表联接分解成多个单个查询，然后在应用程序端实现联接操作，尽管从代码初看上去比较浪费，其实 也只是增加了查询的数量而已，但是这种分解方式有很好的性能优势，查询本身会更高效，能使缓存的效率更高，如果一个表经常改变，那么分解联接就可以减少缓存失效的次数；同时对于MyISAM表来说，每个表一个查询可以更有效地利用表锁，因为查询会锁住单个表较短时间，而不是把多个表长时间锁住，有时在应用程序端进行联接可以更方便扩展数据库。 2.2.5查询缓

17、存 MySQL有一种称为查询缓存的缓存机制，它可以保留查询返回给客户端的完整结果。当缓存命中的时候，服务器马上返回保存的结果，并跳过解析、优化和执行步骤。MySQL将查询缓存完全存储在内存中，缓存不仅仅存储了查询结果，它在某种程度上像一个文件系统，它保持了自身的结构，而这些结构有助于它了解那块内存是空闲的、表和查询之间的映射关系。 查询缓存保留了查询使用过的表，如果表发生了改变，那么缓存就失效了，这样看上去不够高效，某些表的改变不会导致查询结果的改变。但是这种简单方式的开销比较小，而这对于繁忙的系统是很重要的。查询缓存对应用程序完全透明，程序不用知道MySQL是从缓存中返回结果还是通过实际计算

18、返回结果。两种方式返回的结果是一样的，即不会改变语义，不管缓存是打开的还是关闭的，服务器的行为都一样。 缓存并不会自动地比非缓存高校。缓存也需要开销，只有在节省的资源大于开销的时候，缓存才是真正有效率的，这和服务器的负载有关。理论上，可以通过对比在缓存开启和关闭时服务器需要做的工作来了解缓存是否有帮助，但实际上很难精确地计算或者预测查询缓存的好处，有时必须考虑外部因素。例如，查询缓存可以减少产生结果的时间，但它不会减少将结果发送到客户端的时间，而这有可能是主要因素。 从缓存中受益最多的查询可能是需要很多资源来产生结果，但是不需要很多空间来保存的类型，比如集合查询。所以用于存储、返回和失效的代价

19、都较小。当然也有其他类型的查询值得缓存。 检查是否从查询缓存中受益的最简单的办法就是检查缓存命中率，它是缓存提供的查询结果的数量，而不是服务器执行的数量。当服务器收到SELECT语 句的时候，Qcache_hits和Com_select这两个变量会根据查询缓存的情况进行递增，查询缓存命中率的计算公式是：Qcache_hits / ( Qcache_hits + Com_select )。命中率多少才好视情况而定，如果缓存命中率代表了开销最大的查询，那么即使是很低的命中率也有很大的好处。缓存可能会因为碎片、内存不足或数据改变而失效。如果已经给缓存分配了足够的内存，并且把query_cache_m

20、in_res_unit调整到了合适的值，那么大部分缓存失效应该是由数据改变引起的。可以通过检查Com_update, Com_delete等的值知道有多少查询修改了数据，也可以通过检查Qcache_lowmen_prunes的值了解有多少查询因为内存不足而失效。 应该监视服务器实际使用的缓存数量，如果它没有用到分配的内存，就应该把分配给它的内存减少一点。如果由于内存限制引起了缓存失效，那么就应该多分配一些内存，但不用太在意缓存的大小，它比有实际影响的稍大一点或小一点都没有问题，只有在内存有严重浪费或缓存失效太多的时候才需要去考虑它的大小，有时还应该在服务器其他缓存和查询缓存之间找到某种平衡。

21、3.调整配置文件 MySQL的默认配置不适用于使用大量资源，具体的配置文件依赖于服务器的硬件、数据量、查询类型、响应时间、事务持久性和连续性等因素。不能一直期望改变配置文件而带来巨大的性能替身，提升的具体大小取决于工作负载，通常可以通过选择适当的配置参数得到两到三倍的性能提升。在这之后，性能提升就是增量的，通过改变一两个配置参数，可能会看到某些原本运行较慢的查询快了一些，但是，服务器的性能通常不会提升一个数量级，为了达到更大的提升，通常需要检查服务器架构、查询及应用程序的架构。 最好的方式每次只小幅度地改动一两个设置，并且在每次改动之后都进行测试查看效果，也许增减一点就带来了性能提升，但是再增

22、加一点就让性能下降了，那么有可能是过多地请求了某种资源，也有可能是在服务器和操作系统或硬件之间造成了某种不匹配，sort_buffer_size有可能会受到CPU缓存的影响。一些变量也会依赖于其他变量，innodb_log_file_size的最佳大小就依赖于innodb_buffer_pool_size。了解这些需要经验，也需要对系统架构有一定了解。 在对配置进行调优之前，应该对查询和结构进行调优，进行一些最基本的优化，比如添加索引。如果已经对配置文件做了很多调整，再回过头来更改查询和架构，那么就有可能要重新调整配置文件，调优是一个渐进的过程，可以把调整配置文件看成一个两步的过程：在安装的时

23、候使用适当的初始值，然后基于工作负载进行细节调整。 4.内存使用调优 配置MySQL正确地使用内存对性能至关重要。可以认为MySQL的内存消耗有两种范畴：可以控制的和不可控制的。不能控制MySQL使用多少内存来运行服务器、解析查询及管理内部运行，但是可以控制它为特定工作使用多少内存。在特定的系统上，MySQL可能使用的内存有一个绝对的上线。起始点是服务器物理内存的数量。MySQL只需要很少的内存保持连接开启。它也需要一定的基本内存来执行查询，需要在MySQL工作负载处于顶峰的时候为它分配足够的内存，否则查询就会因为内存不足而变得很慢，甚至失败。和为查询指定内存一样，还应当为操作系统保留足够的内

24、存。 5.MySQL I/O调优 某些配置选项可以影响MySQL把数据同步到硬盘和进行恢复的方式，它们通常对性能有很大的影响，因为这其中牵涉了昂贵的I/O操作，同时也代表了性能和数据安全的折中。一般情况下，保证数据被立即而连续地写入磁盘的代价是很高的。 MyISAM表通常在每次写入之后就会把索引的改变刷写到磁盘上。如果准备对一个表做很多改变，那么把它们组成一个批处理就会快很多。 系统绝大多数表使用的是InnoDB引擎，我们不仅可以控制它如何恢复，还可以控制它如何打开表及刷写数据，它们影响了数据恢复和总体性能。InnoDB 的恢复过程是自动的并且在InnoDB启动的时候总会运行，但人为可以影响它

25、。InnoDB有复杂的链式缓冲区和文件，使它可以改进性能并且保证ACID属性。 对于普通使用，一些较重要的配置是InnoDB 日志文件大小、InnoDB 如何刷写日志缓冲区，以及InnoDB 如何执行I/O 。 文件系统 日志 文件 缓冲池缓冲池 I/O 线程 操 作 系 统 缓 存 循环顺序写入 事 务 日 志 日志文件双写 缓冲数据、索引、撤销日志等日志文件- - - - - -数据 文件数据 文件数据文件- - - - - -写入 线程读取线程日志线程 InnoDB 的缓冲区和文件 6. InnoDB 调优 InnoDB 是系统主要用到的存储引擎，它直接影响着系统的事务控制、安全性、备份

26、恢复以及日常的业务查询等。 6.1 InnoDB 事务日志 InnoDB 使用日志来减少提交事务的开销，它不是在每次事务提交的时候就把缓冲池刷写到磁盘上，而是记录了事务。事务对数据和索引做出的改变通常会被映射到表空间的随机位置，所以将这些改变写道磁盘上就会引起随机I/O ，随机I/O 比顺序I/O 开销要高得多。InnoDB 使用自身的日志把随机I/O 转换为顺序I/O ，一旦日志被记录到磁盘上，事务就是持久的了，尽管这时候改变还没有被写道数据文件中。如果一旦发生意外比如断电，InnoDB 可以回放日志并恢复提交了的事务。当然，InnoDB 最终要把改变写到数据文件中，因为日志的大小是 固定的

27、。它以循环的方式写日志，当记录达到日志的底部，就会又从顶部开始，它不会覆盖改变没有被应用到数据文件的记录，因为这会消除提交的事务唯一持久性的记录。 InnoDB使用后台线程智能地把改变写入到文件中。该线程可以把写入集中在一起，然后以更高的顺序写入的方式执行。实际上，事务日志把随机数据文件I/O转换为顺序日志文件和数据文件I/O。把刷写工作后台进行可以让查询完成得更迅速，并且在查询负载很大的时候可以对I/O系统进行缓冲。 InnoDB用多个文件组成一个循环日志系统，通常不用改变默认的日志数量，只须改变每个日志文件的大小就可以了。为了改变日志文件的大小，先关闭MySQL，然后移走旧日志，再重新配置

28、大小，最后重新启动MySQL就行了。要确保干净地关闭MySQL,否则日志文件中就有可能还保留着需要被应用到数据文件的记录。重新启动服务器的时候可以观察错误日志，完成启动后就可以删除旧日志。 为了决定日志文件的理想大小，需要衡量通常数据改变的开销和崩溃时恢复的时间。如果日志太小，InnoDB将会设置更多的检查点，并且导致更多日志写入。如果日志太大，InnoDB在恢复的时候可能就会做大量的工作，增加恢复的时间。另外，数据大小和访问模式也会影响恢复时间。如果数据量很大，在缓冲池中也有许多不干净的页面，比如那些更改没有被应用到数据文件的页面，并且他们在整个数据中均匀分布，那么从崩溃中恢复就会花很长时间

29、，InnoDB不得不扫描日志、检查数据文件，并且按照需要把改动应用到文件上，这意味着大量的读写，另一方面，如果更改是局部化的，比如只有很少比例的数据经常被改动，恢复就会很快，即使数据和日志文件很大也是这样。恢复时间也依赖于典型更改的大小，它和数据行的平均长度有关，较短的行可以在日志中存储更多的改动，所以InnoDB在恢复的时候就会回放更多的改动。 在InnoDB改变数据的时候，它会把这次改动的记录写到日志缓冲里面。日志缓冲被保存在内存中。缓冲写满或事务提交，不管哪种情况先发生，InnoDB 都会把缓冲区写道磁盘上的日志文件中。如果有大型事务，就可以增加缓存文件来减少I/O动作。 日志缓冲区必须

30、被刷写到持久性存储中，以保证提交了的事务能完全持久 化。重要的是知道把日志缓冲写入日志文件和把日志刷写到持久性存储中的区别。在大多数操作系统中，把缓冲写入日志只是简单地数据从InnoDB的内存缓冲区移到操作系统的缓存中，它也在内存中，实际上不会把数据写入持久性存储中。相反的是，将日志刷写到持久性存储中意味着InnoDB要求操作系统把数据刷到缓存外部并且确保写入到磁盘上，这会阻止I/O掉用，直到数据被完全写入。 6.2InnoDB表空间 InnoDB把数据保存在表空间中。表空间实际上是跨越了磁盘上的一个或多个文件的虚拟文件系统。InnoDB出于很多考虑使用了表空间，而不仅仅是为了存储表和索引，它

31、保留了自己的撤销日志、插入缓存以及表空间的其他内部结构。可以使用innodb_data_file_path定义表空间文件，这些文件都在innodb_data_home_dir定义的目录中。 管理表空间也许是一件费力的事情，尤其是它能自动增长，而同时又想收回空间。回收空间的唯一办法就是将数据进行转储、关闭MySQL、删除旧的文件、改变配置、重新启动、让InnoDB创建新文件并且恢复数据。InnoDB对空间的控制很严格，不能简单地移除文件或改变大小。如果表空间崩溃了的话，InnoDB 就不会启动，它在写入负荷很重的情况下会增长的很大，但不能像在MyISAM 中那样随便移动数据。 7.MySQL并发

32、调优 当MySQL在高并发条件下工作的时候，可能会遇到以前未曾遇到过的性能瓶颈。 7.1 MyISAM并发调优 需要很仔细地控制同时进行的读写，以避免读取到不连续的数据。MyISAM 在某些条件下允许并发插入和读取，并且还可以认为调度某些操作，以尽可能少地阻止工作。MyISAM的删除操作不会重新安排整个表，它只是把行标记为已经删除，并且在表中留下了一些空余标识，MyISAM在可能的情况下会优先使 用这些空余，为插入复用空间。如果表是完整的，它就会把新的行拼接在表的最后。即使MyISAM有表级别的锁，它也能在读取的同时把行拼接到表尾，通过禁止读取最后一行做到这一点，这避免了不连续的读取。但当表中

33、间的数据改变的时候，要提供连续读取就困难得多，它只有在到达表尾的时候才允许并发插入。可以使用concurrent_insert变量配置MyISAM的并发插入行为。 7.2 InnoDB并发调优 InnoDB是为高并发设计的，它的结构仍然基于有限内存、单CPU和单磁盘系统（新发布的5.5版本针对InnoDB已有较大改善）。InnoDB某些方面的性能在高并发条件下下降得很快，并且唯一的解决办法就是限制并发。 8.操作系统和硬件优化 MySQL服务器中最弱的部分决定了其性能，它的操作系统和硬件通常也会成为限制因素。磁盘大小、可用内存、CPU资源、网络和连接它们的组件一起决定了系统的最终容量。通常情况

34、下，安装更多内存、重新配置磁盘或升级I/O 是较好的选择。CPU饱和发生在MySQL使用的数据能被装入内存，或者能够尽快根据需要从磁盘上读取的时候，密集地在多表之间执行无索引的连接操作都可能引发CPU饱和。I/O饱和通常发生在需要的数据比内存多得多的时候。如果应用程序分布在网络上，查询数据相当巨大，或者要求很低的延时，瓶颈就会转移到网络上。发现瓶颈通常不是显而易见的事情。某个区域的弱点通常会给其他方面带来压力，问题可能就会表现在其他子系统上面。例如没有足够的内存，MySQL就会刷写数据，为需要的数据腾出空间，然后再马上把数据重新读回来，因此内存不足就变线为I/O容量不够，同样地，达到饱和的内存

35、问题也会表现为CPU问题。 拥有大量内存的最大原因不是能够在内存中保存大量的数据，最终目的是可以避免磁盘I/O，访问磁盘的速度比访问内存慢几个数量级，关键就是在于平衡内存大小、速度、开销和其他因素，以得到好的性能。 数据库服务器同时使用了随机I/O和顺序I/O，随机I/O从缓存中得益是最 多的。磁盘中的顺序操作都比随机操作快，顺序访问内存中的数据也比随机访问快，两者可能会出现几个数量级的差别。存储引擎能更快地执行顺序读取，随机读取通常意味着存储引擎需要做索引操作，因此，对于随机读取I/O问题，添加内存是最佳选择。 9.大数据表的设计优化 平台的主要性能瓶颈主要是在大表查询这块，表写入目前还没有

36、形成压力，以下主要阐述几种设计思路，有的只会在某种特定业务中会用到，需要通过具体业务来对表设计进行具体分析。 9.1. 垂直切分 垂直切分主要是针对数据库架构而非表的设计而言的，在这里提出来是因为它会影响到大表结构的设计。 系统的总体功能是由多个功能模块所组成，而每一个功能模块所需要的数据对应到数据库中就是一个或多个表。各个功能模块相互之间的接口越统一，越少，系统的耦合度就越低，实现数据的垂直切分就越容易。若某一个功能模块其整体数据量特别大或者因该功能并发读写特别频繁而形成瓶颈，且与系统的其他功能模块耦合度很低，则可以考虑将该功能模块整体垂直切分，将其部署在单独的主机上，分摊整体系统的压力。 9.2. 水平切分 水平切分是针对表按照数据行来切分，即将表中的某些行切分到一个数据库，而另外的某些行又切分到其他的数据库中。切分必须按照某种特定的规则来进行，这样才能够较容易地判定各行数据被切分到那个数据库中了。可根据关键字段的取值（奇偶性，取模），时间字段的范围等来进行水平切分，结合实际业务需要和数据量来定义切分的粒度。 如果某个功能存在一张大数据量表而影响性能，而整个功能模块的大部分核心表都可以通过某个字段（如：userid）来进行关联，那这个字段就是一个进行 水平切分的关键字段，这样所有可以与该字段关联的表都可以按照特定规则被水平切分到同一个数