ed变量显示了有多少表被锁住了并且导致服务器级的锁等待，I
oDB的行级锁不会使该变量增加。如果该值较高并且正在增加，则说明存在严重的并发瓶颈，这时应该考虑使用I
oDB或另外使用行级锁的存储引擎，或者手动对大表进行分区，并优化查询，启用并发插入或对锁设置进行优化。本系统该变量在半小时内变化幅度不超过3，不必调整。
2MySQL优化策略优化策略
21索引策略索引是帮助MySQL高效获取数据的数据结构，它对于高性能非常关键，因此建立索引是现实中性能问题的首要原因。索引在数据越大的时候越重要。规模小，负载轻的数据库即使没有索引，也能有好的性能，但是当数据增加的时候，性能就会下降。MySQL有多种类型类型的索引，它们各有自己的性能特点。索引是在存储引擎层实现的，而不是在服务器层，因此它们并不是标准化的，每个引擎的索引工作方式略有不同，并不是所有的引擎都支持所有类型的索引。即使多个引擎支持同样的索引，他们的实现方式也可能有所不同。MySQL索引类型的各自特点可以查阅相关资料去进一步了解。即使已经了解了关于索引的知识，但也许还不知道如何从实际的表开始。虽然通常情况下是检查系统中最常运行的查询，但往往性能瓶颈可能就出现在不那么经常进行的插入或更新操作，要避免在不知道什么查询会使用索引之前就创建它这种常见错误，并且要考虑是否所有的索引能形成一个优化的配置。
f有时只从查询就可以知道需要什么索引，只要把它们加上就可以了。但是有时各种类型的查询，却不能找到适合他们的完美索引，这种情况就需要一些折中。为了找到最佳平衡，应该进行测试和剖析。第一个要检查的就是响应时间，要考虑为任何耗时很长的查询创建索引，然后检查导致最大负载的查询，并且添加索引予以支持。如果系统正好碰到了内存、CPU或磁盘瓶颈，也要把他们考虑进去。例如，如果运行了很长的聚合查询以生成汇总，那么磁盘会因为使用了支持GROUPBY查询的索引而得益。通常情况下，都要试着扩展索引，而不是新增索引，维护一个多列索引要比维护多个单列索引容易，但不能过多否则就会有麻烦，使用太多这种列表也会造成优化器要计算的组合激增，并最终降低查询速度。如果不知道查询的分布，就尽可能使索引变得更有选择性，这样更有好处。即使已经创建了正确的索引，还需要维护表和索引以确保它们能很好的工作。22查询性能优化优化数据访问查询性能低下的最基本原因就是访问了太多数据。一些查询不可避免地要筛选r