论⽂中如何写mysql的介绍_mysql优化写论⽂，从哪⼏⽅⾯⼊
⼿啊解决⽅法
引⽤
第7章：优化
⽬录
7.1. 优化概述
7.1.1. MySQL设计局限与折衷
7.1.2. 为可移植性设计应⽤程序
7.1.3. 我们已将MySQL⽤在何处？
7.1.4. MySQL基准套件
7.1.5. 使⽤⾃⼰的基准
7.2. 优化SELECT语句和其它查询
7.2.1. EXPLAIN语法(获取SELECT相关信息)
7.2.2. 估计查询性能
7.2.3. SELECT查询的速度
7.2.4. MySQL怎样优化WHERE⼦句
7.2.5. 范围优化
7.2.6. 索引合并优化
7.2.7. MySQL如何优化IS NULL
7.2.8. MySQL如何优化DISTINCT
7.2.9. MySQL如何优化LEFT JOIN和RIGHT JOIN
7.2.10. MySQL如何优化嵌套Join
7.2.11. MySQL如何简化外部联合
7.2.12. MySQL如何优化ORDER BY
7.2.13. MySQL如何优化GROUP BY
7.2.14. MySQL如何优化LIMIT
7.2.15. 如何避免表扫描
7.2.16. INSERT语句的速度
7.2.17. UPDATE语句的速度
7.2.18. DELETE语句的速度
7.2.19. 其它优化技巧
7.3. 锁定事宜
7.3.1. 锁定⽅法
7.3.2. 表锁定事宜
7.4. 优化数据库结构
7.4.1. 设计选择
7.4.2. 使你的数据尽可能⼩
7.4.3. 列索引
7.4.4. 多列索引
7.4.5. MySQL如何使⽤索引
7.4.6. MyISAM键⾼速缓冲
7.4.7. MyISAM索引统计集合
7.4.8. MySQL如何计算打开的表
7.4.9. MySQL如何打开和关闭表
7.4.10. 在同⼀个数据库中创建多个表的缺陷
7.5. 优化MySQL服务器
7.5.1. 系统因素和启动参数的调节
7.5.2. 调节服务器参数
7.5.3. 控制查询优化器的性能
7.5.4. 编译和链接怎样影响MySQL的速度
7.5.5. MySQL如何使⽤内存
7.5.6. MySQL如何使⽤DNS
7.6. 磁盘事宜
7.6.1. 使⽤符号链接
优化是⼀个复杂的任务，因为最终要求了解整个待优化的系统。尽管可以进⾏局部优化⽽不需要了解系统或应⽤程序，为了优化得更好，你必须知道更多的信息。
本章解释并给出不同的优化MySQL的⽅法⽰例。但要记住总有⼀些其它⽅法使系统更快，尽管需要更多的⼯作。
7.1. 优化概述
7.1.1. MySQL设计局限与折衷
7.1.2. 为可移植性设计应⽤程序
7.1.3. 我们已将MySQL⽤在何处？
7.1.4. MySQL基准套件
7.1.5. 使⽤⾃⼰的基准
使⼀个系统更快的最重要因素当然是基本设计。此外，还需要知道系统正做什么样的事情，以及瓶颈是什么。
最常见的系统瓶颈是：
磁盘搜索。需要花时间从磁盘上到⼀个数据，⽤在现代磁盘的平均时间通常⼩于10ms，因此理论上
mysql下载哪个盘
我们能够每秒⼤约搜索1000次。这个时间在新磁盘上提⾼不⼤并且很难为⼀个表进⾏优化。优化它的⽅法是将数据分布在多个磁盘上。
磁盘读/写。当磁盘放⼊正确位置后，我们需要从中读取数据。对于现代的磁盘，⼀个磁盘⾄少传输10-20Mb/s的吞吐。这⽐搜索要容易优化，因为你能从多个磁盘并⾏地读。
CPU周期。我们将数据读⼊内存后，需要对它进⾏处理以获得我们需要的结果。表相对于内存较⼩是最常见的限制因素。但是对于⼩表，速度通常不成问题。
· 内存带宽。当CPU需要的数据超出CPU缓存时，主缓存带宽就成为内存的⼀个瓶颈。这在⼤多数系统正是⼀个不常见的瓶颈但是你应该知道它。
7.1.1. MySQL设计局限与折衷
当使⽤MyISAM存储引擎时，MySQL使⽤极快速的表锁定，以便允许多次读或⼀次写。使⽤该存储引擎的最⼤问题出现在同⼀个表中进⾏混合稳定数据流更新与慢速选择。如果这只是某些表的问题，你可以使⽤另⼀个存储引擎。参见第15章：存储引擎和表类型。
MySQL可以使⽤事务表和⾮事务表。为了更容易地让⾮事务表顺利⼯作(如果出现问题不能回滚)，MySQL采⽤下述规则。请注意这些规则只适⽤于不运⾏在严格模式下或为INSERT或UPDATE使⽤IG
NORE规定程序时。
· 所有列有默认值。请注意当运⾏在严格SQL模式(包括TRADITIONAL SQL模式)时，必须为NOT NULL列指定默认值。
· 如果向列内插⼊不合适的或超出范围的值，MySQL将该列设定为“最好的可能的值”，⽽不是报告错误。对于数字值，为0、可能的最⼩值或最⼤值。对于字符串，为空字符串或列内可以保存的字符串。请注意当运⾏在严格模式或TRADITIONAL SQL模式时该⾏为不 适⽤。
· 所有表达式的计算结果返回⼀个表⽰错误状况的信号。例如，1/0返回NULL。(使⽤ERROR_FOR_DIVISION_BY_ZERO SQL模式可以更改该⾏为)。
如果正使⽤⾮事务表，不应该使⽤MySQL来检查列的内容。⼀般情况，最安全的(通常是最快的)⽅法径是让应⽤程序确保只向数据库传递合法值。
相关详细信息参见1.8.6节，“MySQL处理约束的⽅式”和13.2.4节，“INSERT语法”或5.3.2节，“SQL服务器模式”。
7.1.2. 为可移植性设计应⽤程序
因为不同SQL服务器实现了标准SQL的不同部分，需要花功夫来编写可移植的SQL应⽤程序。对很简单的选择/插⼊，很容易实现移植，但是需要的功能越多则越困难。如果想要应⽤程序对很多数据库系统都快，它变得更难！
为了使⼀个复杂应⽤程序可移植，你需要选择它应该⼯作的SQL服务器，并确定这些服务器⽀持什么特性。
所有数据库都有⼀些弱点。这就是它们不同的设计折衷导致的不同⾏为。
可以使⽤MySQL的crash-me程序来出能⽤于数据库服务器选择的函数、类型和限制。crash-me并不能出所有的特性，但是其⼴度仍然很合理，可以进⾏⼤约450个测试。
crash-me可以提供的⼀种类型的信息的例⼦：如果想要使⽤Informix或DB2，不应该使⽤超过18个字符的列名。
crash-me程序和MySQL基准程序是独⽴于数据库的。通过观察它们是如何编写的，编可以知道必须为编写独⽴于数据库的应⽤程序做什么。基准本⾝可在MySQL源码分发的“sql-bench”⽬录下到。它们⽤DBI数据库接⼝以Perl写成。使⽤DBI本⾝即可以解决部分移植性问题，因为它提供与数据库⽆关的的存取⽅法。
如果你为数据库的独⽴性⽽努⼒，需要很好地了解每个SQL服务器的瓶颈。例如，MySQL在检索和更新MyISAM表记录⽅⾯很快，但是在同⼀个表上混合慢速读者和写者⽅⾯有⼀个问题。另⼀⽅⾯，当你试图访问最近更新了(直到它们被刷新到磁盘上)的⾏时，在Oracle中有⼀个很⼤的问题。事务数据库总的来说在从记录⽂件表中⽣成总结表⽅⾯不是很好，因为在这种情况下，⾏锁定⼏乎没有⽤。
为了使应⽤程序“确实”独⽴于数据库，需要定义⼀个容易扩展的接⼝，⽤它可操纵数据。因为C++在⼤多数系统上可以适⽤，使⽤数据库的⼀个C++ 类接⼝是有意义的。
如果你使⽤某个数据库特定的功能(例如MySQL

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。