©
Ce document utilise Manuel du site Web PHP chinois Libérer
目录
本章包含许多在你处理MySQL代码时需要了解的你事情。如果你想投入到MySQL的开发中，或想要接触到最新的中间版本的代码，或者就是想了解开发的进度，请参阅2.8.3节，“从开发源代码树安装”的说明。如果你对MySQL的内部插件感兴趣，你也可以订阅我们的内部插件邮件列表。这个列表的流量相对低一些。欲知如何订阅的详情，请参阅1.7.1.1节，“MySQL邮件列表”。在MySQL AB 的所有开发人员都在内部插件列表里， 此外，我们帮助那些正在处理MySQL代码的人。请随意使用这个邮件列表来问代码有关的问题，也可用它来发送你想奉献给MySQL项目的 补丁！
MySQL服务器创建如下线程：
TCP/IP 连接线程处理所有连接请求，并为每一个连接创建一个新的专用线程来处理认证和SQL查询处理。
Windows NT 平台上有一个名为管道处理程序（pipe handler）的线程，它和名为管道连接请求（pipe connect requests）的TCP/IP连接线程做同样的工作。
信号线程处理所有的信号，这个线程通常也处理报警和调用process_alarm() 函数来强制使得空闲时间太长的连接超时。
若mysqld是与DUSE_ALARM_THREAD线程一起编译的，这个专用线程是处理 创建的警报的。这个线程用在一些sigwait()函数有问题的系统上，或者用在你想在应用程序中使用thr_alarm()代码而不带专用信号处理线程之时。
若想使用flush_time=val选项，会创建一个专用线程以给定的时间间隔刷新所有表格。
每个连接都有它自己的线程。
每个被使用INSERT DELAYED 的不同表格都会有自己的线程。
若使用了master-host, 则会创建一个从属的复制线程从主线程读取并实施更新。
mysqladmin processlist 仅显示连接，INSERT DELAYED, 及复制线程
包含在Unix源码和二进制分发版中的测试系统可以让用户和开发人员对MySQL代码施行回归测试。这些测试可以在Unix上进行，目前它们还不能在原生的Windows环境下进行。
当前的测试案例套件不能在MySQL中测试所有东西，但是它能发现SQL处理代码，OS/library文件中大多数明显的缺陷，并且在测试复件方面也是非常彻底的。我们的终极目标是对100%的代码进行测试。我们欢迎大家给我们的测试套件添加内容。你可能会特别想贡献出那些检查你系统里功能性危机的测试，因为这将确保未来所有发行版的MySQL会与你的应用程序一起更好地运行。
测试系统包括一个测试语言解释器(mysqltest)，一个运行所有测试的外壳脚本(mysql-test-run)，用专用语言编写的测试案例，以及它们的预期结果。在系统上编译好之后，在源代码的root下键入make test 或mysql-test/mysql-test-run。如果安装了一个二进制分发版， cd 到安装root (如 /usr/local/mysql), 然后键入 scripts/mysql-test-run。所有测试应该都通过，假使有没通过的，若是一个MySQL里的缺陷，你可以试着找找是因为什么，并且报告这个问题。请参阅27.1.2.3节，“在MySQL测试套件里报告缺陷”。
如果你想要运行测试套件的机器上已经运行了一个 mysqld ，只要它不占用9306 和 9307端口，就不用停掉它。如果占用了其中的一个，以可以编辑mysql-test-run把主端口和（或）从端口号改为其它可用的。.
可使用下面指令运行单个测试案例 mysql-test/mysql-test-run test_name.
若一个测试未通过，你可以用--force选项来检查运行着的mysql-test-run看是否是别的测试未通过。
你可以用mysqltest 语言编写你自己的测试案例。不幸地是，我们还没有写完相关方面完整地文档。但是，你可以查看我们现有的测试案例，并将它们作为范例。下面几点将有助于你入手：
测试位于 mysql-test/t*.MYI，检查所有的MyISAM表，并重启mysqld。这样，就能确保从干净的状态运行服务器。请参见第5章：数据库管理。
使用“--log”选项启动mysqld，并根据写入日志的信息确定是否某些特殊的查询杀死了服务器。约95%的缺陷与特定的查询有关。正常情况下，这是服务器重启前日志文件中最够数个查询中的1个。请参见5.11.2节，“通用查询日志”。如果能够用特殊查询重复杀死MySQL，即使在发出查询前检查了所有表的情况下也同样，那么你就应能确定缺陷，并应提交关于该缺陷的缺陷报告。请参见1.7.1.3节，“如何通报缺陷和问题”。
尝试提供一个测试范例，我们应能利用该范例重复问题。请参见E.1.6节，“如果出现表崩溃，请生成测试案例”。
请在mysql-test目录下并根据MySQL基准进行测试。请参见27.1.2节，“MySQL测试套件”。它们能相当良好地测试MySQL。你也可以为基准测试增加代码，以模拟你的应用程序。基准测试可在源码分发版的sql-bench目录下找到，对于二进制分发版，可在MySQL安装目录下的sql-bench目录下找到。
尝试使用fork_big.pl脚本（它位于源码分发版的测试目录下）。
如果你将MySQL配置为调试模式，如果某事出错，可更为容易地搜集关于可能错误的信息。如果将MySQL配置为调试模式，可生成1个安全的内存分配程序，可使用它发现某些错误。此外，它还提供了很多输出，这类输出与出现的问题相关。在configure上使用“--with-debug”或“--with-debug=full”选项重新配置MySQL，然后再编译它。请参见E.1节，“调试MySQL服务器”。
确保为你的操作系统应用了最新的补丁。
对mysqld使用“--skip-external-locking”选项。在某些系统上，lockd锁定管理器不能正确工作，“--skip-external-locking”选项通知mysqld不使用外部锁定。（这意味着，你不能在相同的数据目录上运行2个mysqld服务器，如果使用myisamchk，必须谨慎。然而，尝试将该选项用作测试也是有益的）。
当mysqld看上去正在运行但并未响应时，是否运行了mysqladmin -u root processlist？某些时候，即使你认为mysqld处于闲置状态时，实际情况并非如此。问题可能是因为所有连接均已使用，或存在某些内部锁定问题。即使在该情况下，mysqladmin -u root processlist通常能够进行连接，并能提供关于当前连接数以及其状态的有用信息。
在运行其他查询的同时，在单独的窗口中运行命令mysqladmin -i 5 status或mysqladmin -i 5 -r status，以生成统计信息。
尝试采用下述方法：
从gdb（或另一个调试器）启动mysqld。请参见E.1.3节，“在gdb环境下调试mysqld”。
运行测试脚本。
在3个较低层面上输出backtrace（向后跟踪）和局部变量。在gdb中，当mysqld在gdb内崩溃时，可使用下述命令完成该任务：
backtrace
info local
up
info local
up
info local
使用gdb，你还能检查与info线程共存的线程，并切换至特定的线程N，其中，N是线程ID。
尝试用Perl脚本模拟你的应用程序，强制MySQL崩溃或行为异常。
发送正常的缺陷报告。请参见1.7.1.3节，“如何通报缺陷和问题”。应比通常的报告更详细。由于MySQL是为很多人提供服务的，它可能因仅存在于你的计算机上的某事崩溃（例如，与你的特定系统库有关的错误）。
如果你遇到与包含动态长度行的表有关的问题，而且你仅使用VARCHAR列（而不是BLOB或TEXT列），可尝试用ALTER TABLE将所有VARCHAR列更改为CHAR列。这样，就会强制MySQL使用固定大小的行。固定大小的行占用的空间略多，但对损坏的容忍度更高。
目前的动态行代码在MySQL AB已使用多年，很少遇到问题，但从本质上看，动态长度行更倾向于出现错误，因此，不妨尝试采用该策略以查看它是否有帮助，这不失为一个好主意。
诊断问题时不要将你的服务器硬件排除在外。有缺陷的硬件能够导致数据损坏。对硬件进行故障诊断与排除操作时，尤其应注意RAM和硬盘驱动器。
在本节中，介绍了MySQL响应磁盘满错误的方式（如“设备上无剩余空间”），以及响应超配额错误的方式（如“写入失败”或“达到了用户屏蔽限制”）。
本节介绍的内容与写入MyISAM表有关。它也适用于写入二进制日志文件和二进制索引文件，但对“row”和“record”的应用应被视为“event”。
出现磁盘满状况时，MySQL将：
每分钟检查一次，查看是否有足够空间写入当前行。如果有足够空间，将继续，就像什么也未发生一样。
每10分钟将1个条目写入日志文件，提醒磁盘满状况。
为了减轻问题，可采取下述措施：
要想继续，仅需有足够的磁盘空间以插入所有记录。
要想放弃线程，必须使用mysqladmin kill。下次检查磁盘时将放弃线程（1分钟）。
其他线程可能会正在等待导致磁盘满状况的表。如果有数个“已锁定”的线程，杀死正在磁盘满状况下等待的某一线程，以便允许其他线程继续。
对前述行为的例外是，当你使用REPAIR TABLE或OPTIMIZE TABLE时，或当索引是在LOAD DATA INFILE或ALTER TABLE语句后、在批操作中创建的。所有这些语句能创建大的临时文件，如果保留这些文件，会导致系统其他部分出现大问题。如果在MySQL执行这类操作的同时磁盘已满，它将删除大的临时文件，并将表标注为崩溃。但对于ALTER TABLE例外，旧表保持不变。
MySQL使用环境变量TMPDIR的值作为保存临时文件的目录的路径名。如果未设置TMPDIR，MySQL将使用系统的默认值，通常为/tmp、/var/tmp或/usr/tmp。如果包含临时文件目录的文件系统过小，可对mysqld使用“—tmpdir”选项，在具有足够空间的文件系统内指定1个目录。
在MySQL 5.1中，“—tmpdir”选项可被设置为数个路径的列表，以循环方式使用。在Unix平台上，路径用冒号字符“:”隔开，在Windows、NetWare和OS/2平台上，路径用分号字符“;”隔开。注意，为了有效分布负载，这些路径应位于不同的物理磁盘上，而不是位于相同磁盘的不同分区中。
如果MySQL服务器正作为复制从服务器使用，不应将“--tmpdir”设置为指向基于内存的文件系统的目录，或当服务器主机重启时将清空的目录。对于复制从服务器，需要在机器重启时仍保留一些临时文件，以便能够复制临时表或执行LOAD DATA INFILE操作。如果在服务器重启时丢失了临时文件目录下的文件，复制将失败。
MySQL会以隐含方式创建所有的临时文件。这样，就能确保中止mysqld时会删除所有临时文件。使用隐含文件的缺点在于，在临时文件目录所在的位置中，看不到占用了文件系统的大临时文件。
进行排序时（ORDER BY或GROUP BY），MySQL通常会使用1个或多个临时文件。所需的最大磁盘空间由下述表达式决定：
(length of what is sorted + sizeof(row pointer))
* number of matched rows
* 2
“row pointer”（行指针）的大小通常是4字节，但在以后，对于大的表，该值可能会增加。
对于某些SELECT查询，MySQL还会创建临时SQL表。它们不是隐含表，并具有SQL_*形式的名称。
ALTER TABLE会在与原始表目录相同的目录下创建临时表。
对于服务器用来与本地客户端进行通信的Unix套接字文件，其默认位置是/tmp/mysql.sock。这有可能导致问题，原因在于，在某些版本的Unix上，任何人都能删除/tmp目录下的文件。
在大多数Unix版本中，可对/tmp目录进行保护，使得文件只能被其所有这或超级用户（根用户）删除。为此，以根用户身份登录，并使用下述命令在/tmp目录上设置粘着位：
shell> chmod +t /tmp
通过执行ls -ld /tmp，可检查是否设置了粘着位。如果最后一个许可字符是“t”，表明设置了粘着位。
另一种方法是改变服务器创建Unix套接字文件的位置。如果进行了这类操作，还应让客户端程序知道文件的位置。能够以多种不同方式指定文件位置：
在全局或局部选项文件中指定路径。例如，将下述行置于文件/etc/my.cnf中：
[mysqld]
socket=/path/to/socket
[client]
socket=/path/to/socket
请参见4.3.2节，“使用选项文件”。
在运行客户端程序时，在命令行上为mysqld_safe指定“--socket”选项。
将MYSQL_UNIX_PORT环境变量设置为Unix套接字文件的路径。
重新从源码编译MySQL，以使用不同的默认Unix套接字文件位置。运行configure时，用“--with-unix-socket-path”选项定义文件路径。请参见2.8.2节，“典型配置选项”。
用下述命令连接服务器，能够测试新的套接字位置是否工作：
shell> mysqladmin --socket=/path/to/socket version
在默认情况下，MySQL搜索不区分大小写（但某些字符集始终区分大小写，如czech）。这意味着，如果你使用col_name LIKE 'a%'进行搜索，你将获得以A或a开始的所有列。如果打算使搜索区分大小写，请确保操作数之一具有区分大小写的或二进制校对。例如，如果你正在比较均适用latin1字符集的列和字符串，可使用COLLATE操作符，使1个操作数具有latin1_general_cs或latin1_bin校对特性。例如：
col_name COLLATE latin1_general_cs LIKE 'a%'
col_name LIKE 'a%' COLLATE latin1_general_cs
col_name COLLATE latin1_bin LIKE 'a%'
col_name LIKE 'a%' COLLATE latin1_bin
如果希望总是以区分大小写的方式处理列，可使用区分大小写的或二进制校对声明它。请参见13.1.5节，“CREATE TABLE语法”。
简单的比较操作（>=, >, =, <, <=, 排序和分组）基于每个字符的“排序值”。具有相同排序值的字符（如‘E’, ‘e’,和‘é’）将被当作相同的写字符。
DATE值的格式是'YYYY-MM-DD'。按照标准的SQL，不允许其他格式。在UPDATE表达式以及SELECT语句的WHERE子句中应使用该格式。例如：
mysql> SELECT * FROM tbl_name WHERE date >= '2003-05-05';
为了方便，如果日期是在数值环境下使用的，MySQL会自动将日期转换为数值（反之亦然）。它还具有相当的智能，在更新时或在与TIMESTAMP、DATE或DATETIME列比较日期的WHERE子句中，允许“宽松的”字符串形式（“宽松形式”表示，任何标点字符均能用作各部分之间的分隔符。例如，'2004-08-15'和'2004#08#15'是等同的）。MySQL还能转换不含任何分隔符的字符串（如'20040815'），前体是它必须是有意义的日期。
使用<、<=、=、>=、>、或BETWEEN操作符将DATE、TIME、DATETIME或TIMESTAMP与常量字符串进行比较时，MySQL通常会将字符串转换为内部长整数，以便进行快速比较（以及略为“宽松”的字符串检查）。但是，该转换具有下述例外：
比较两列时
将DATE、TIME、DATETIME或TIMESTAMP列与表达式进行比较时
使用其他比较方法时，如IN或STRCMP()。
对于这些例外情形，会将对象转换为字符串并执行字符串比较，采用该方式进行比较。
为了保持安全，假定按字符串比较字符串，如果你打算比较临时值和字符串，将使用恰当的字符串函数。
对于特殊日期'0000-00-00'，能够以'0000-00-00'形式保存和检索。在MyODBC中使用'0000-00-00'日期时，对于MyODBC 2.50.12或更高版本，该日期将被自动转换为NULL，这是因为ODBC不能处理这类日期。
由于MySQL能够执行前面所介绍的转换，下述语句均能正常工作：
mysql> INSERT INTO tbl_name (idate) VALUES (19970505);
mysql> INSERT INTO tbl_name (idate) VALUES ('19970505');
mysql> INSERT INTO tbl_name (idate) VALUES ('97-05-05');
mysql> INSERT INTO tbl_name (idate) VALUES ('1997.05.05');
mysql> INSERT INTO tbl_name (idate) VALUES ('1997 05 05');
mysql> INSERT INTO tbl_name (idate) VALUES ('0000-00-00');
mysql> SELECT idate FROM tbl_name WHERE idate >= '1997-05-05';
mysql> SELECT idate FROM tbl_name WHERE idate >= 19970505;
mysql> SELECT MOD(idate,100) FROM tbl_name WHERE idate >= 19970505;
mysql> SELECT idate FROM tbl_name WHERE idate >= '19970505';
但是，下述语句不能正常工作：
mysql> SELECT idate FROM tbl_name WHERE STRCMP(idate,'20030505')=0;
STRCMP()是一种字符串函数，它能将idate转换为'YYYY-MM-DD'格式的字符串，并执行字符串比较。它不能将'20030505'转换为日期'2003-05-05'并进行日期比较。
如果你正在使用ALLOW_INVALID_DATES SQL模式，MySQL允许以仅执行给定的有限检查方式保存日期：MySQL仅保证天位于1～31的范围内，月位于1～12的范围内。
这样就使得MySQL很适合于Web应用程序，其中，你能获得三个不同字段中的年、月、日值，也能准确保存用户插入的值（无日期验证）。
如果未使用NO_ZERO_IN_DATE SQL模式，“天”和“月”部分可能为0。如果你打算将生日保存在DATE列而且仅知道部分日期，它十分方便。
如果未使用NO_ZERO_DATE SQL模式，MySQL也允许你将'0000-00-00'保存为“伪日期”。在某些情况下，它比使用NULL值更方便。
如果无法将日期转换为任何合理值，“0”将保存在DATE列中，并被检索为'0000-00-00'。这是兼顾速度和便利性的事宜。我们认为，数据库服务器的职责是检索与你保存的日期相同的日期（即使在任何情况下，数据在逻辑上不正确也同样）。我们认为，对日期的检查应由应用程序而不是服务器负责。
如果你希望MySQL检查所有日期并仅接受合法日期（除非由IGNORE覆盖），应将sql_mode设置为"NO_ZERO_IN_DATE,NO_ZERO_DATE"。
对于SQL的新手，NULL值的概念常常会造成混淆，他们常认为NULL是与空字符串''相同的事。情况并非如此。例如，下述语句是完全不同的：
mysql> INSERT INTO my_table (phone) VALUES (NULL);
mysql> INSERT INTO my_table (phone) VALUES ('');
这两条语句均会将值插入phone（电话）列，但第1条语句插入的是NULL值，第2条语句插入的是空字符串。第1种情况的含义可被解释为“电话号码未知”，而第2种情况的含义可被解释为“该人员没有电话，因此没有电话号码”。
为了进行NULL处理，可使用IS NULL和IS NOT NULL操作符以及IFNULL()函数。
在SQL中，NULL值与任何其它值的比较（即使是NULL）永远不会为“真”。包含NULL的表达式总是会导出NULL值，除非在关于操作符的文档中以及表达式的函数中作了其他规定。下述示例中的所有列均返回NULL：
mysql> SELECT NULL, 1+NULL, CONCAT('Invisible',NULL);
如果打算搜索列值为NULL的列，不能使用expr = NULL测试。下述语句不返回任何行，这是因为，对于任何表达式，expr = NULL永远不为“真”：
mysql> SELECT * FROM my_table WHERE phone = NULL;
要想查找NULL值，必须使用IS NULL测试。在下面的语句中，介绍了查找NULL电话号码和空电话号码的方式：
mysql> SELECT * FROM my_table WHERE phone IS NULL;
mysql> SELECT * FROM my_table WHERE phone = '';
更多信息和示例，请参见3.3.4.6节，“使用NULL值”。
如果你正在使用MyISAM、InnoDB、BDB、或MEMORY存储引擎，能够在可能具有NULL值的列上增加1条索引。如不然，必须声明索引列为NOT NULL，而且不能将NULL插入到列中。
用LOAD DATA INFILE读取数据时，对于空的或丢失的列，将用''更新它们。如果希望在列中具有NULL值，应在数据文件中使用\N。在某些情况下，也可以使用文字性单词“NULL”。请参见13.2.5 “LOAD DATA INFILE语法” 。
使用DISTINCT、GROUP BY或ORDER BY时，所有NULL值将被视为等同的。
使用ORDER BY时，首先将显示NULL值，如果指定了DESC按降序排列，NULL值将最后显示。
对于聚合（累计）函数，如COUNT()、MIN()和SUM()，将忽略NULL值。对此的例外是COUNT(*)，它将计数行而不是单独的列值。例如，下述语句产生两个计数。首先计数表中的行数，其次计数age列中的非NULL值数目：
mysql> SELECT COUNT(*), COUNT(age) FROM person;
对于某些列类型，MySQL将对NULL值进行特殊处理。如果将NULL插入TIMESTAMP列，将插入当前日期和时间。如果将NULL插入具有AUTO_INCREMENT属性的整数列，将插入序列中的下一个编号。
SELECT SQRT(a*b) AS root FROM tbl_name GROUP BY root HAVING root > 0;
SELECT id, COUNT(*) AS cnt FROM tbl_name GROUP BY id HAVING cnt > 0;
SELECT id AS 'Customer identity' FROM tbl_name;
标准SQL不允许在WHERE子句中已用列别名。这是因为，执行WHERE代码时，可能尚未确定列值。例如，下述查询是非法的：
SELECT id, COUNT(*) AS cnt FROM tbl_name WHERE cnt > 0 GROUP BY id;
执行WHERE语句以确定哪些行应被包含在GROUP BY部分中，而HAVING用于确定应使用结果集中的哪些行。
执行ROLLBACK（回滚）时，如果收到下述消息，表示事务中使用的1个或多个表不支持事务：
警告：某些更改的非事务性表不能被回滚。
这些非事务性表不受ROLLBACK语句的影响。
如果在事务中意外地混合了事务性表和非事务性表，导致该消息的最可能原因是，你认为本应是事务性的表实际上不是。如你试图使用mysqld服务器不支持的事务性存储引擎（或用启动选项禁止了它）创建表，就可能出现该情况。如果mysqld不支持存储引擎，它将以MyISAM表创建表，这是非事务性表。
可使用下述语句之一检查表的标类型：
SHOW TABLE STATUS LIKE 'tbl_name';
SHOW CREATE TABLE tbl_name;
请参见13.5.4.18节，“SHOW TABLE STATUS语法以及13.5.4.5节，“SHOW CREATE TABLE语法”。
使用下述语句，可检查mysqld服务器支持的存储引擎：
SHOW ENGINES;
也可以使用下述语句，检查与你感兴趣的存储引擎有关的变量值：
SHOW VARIABLES LIKE 'have_%';
例如，要想确定InnoDB存储引擎是否可用，可检查have_innodb变量的值。
请参见13.5.4.8节，“SHOW ENGINES语法”和13.5.4.21节，“SHOW VARIABLES语法”。
如果有使用了很多表的复杂查询，但未返回任何行，应采用下述步骤找出什么出错：
用EXPLAIN测试查询，以检查是否发现某事显然出错。请参见7.2.1节，“EXPLAIN语法（获取关于SELECT的信息）”。
仅选择在WHERE子句中使用的列。
从查询中1次删除1个表，直至返回了某些行为止。如果表很大，较好的主意是在查询中使用LIMIT 10。
对于具有与上次从查询中删除的表匹配的行的列，发出SELECT查询。
如果将FLOAT或DOUBLE列与具有数值类型的数值进行比较，不能使用等式(=)比较。在大多数计算机语言中，该问题很常见，这是因为，并非所有的浮点值均能以准确的精度保存。在某些情况下，将FLOAT更改为DOUBLE可更正该问题。请参见A.5.8节，“与浮点比较有关的问题”。
如果仍不能找出问题之所在，请创建能与显示问题的“mysql test < query.sql”一起运行的最小测试。通过使用mysqldump --quick db_name tbl_name_1 ... tbl_name_n > query.sql转储表，可创建测试文件。在编辑器中打开文件，删除某些插入的行（如果有超出演示问题所需的行），并在文件末尾添加SELECT语句。
通过执行下述命令，验证测试文件能演示问题：
shell> mysqladmin create test2
shell> mysql test2 < query.sql
使用mysqlbug将测试文件张贴到哟娜通用MySQL邮件列表。请参见1.7.1.1节，“The MySQL邮件列表”。
浮点数有时会导致混淆，这是因为它们无法以准确值保存在计算机体系结构中。你在屏幕上所看到的值通常不是数值的准确值。对于FLOAT和DOUBLE列类型，情况就是如此。DECIMAL列能保存具有准确精度的值，这是因为它们是由字符串表示的。
在下面的示例中，介绍了使用DOUBLE时的问题：
mysql> CREATE TABLE t1 (i INT, d1 DOUBLE, d2 DOUBLE);
mysql> INSERT INTO t1 VALUES (1, 101.40, 21.40), (1, -80.00, 0.00),
-> (2, 0.00, 0.00), (2, -13.20, 0.00), (2, 59.60, 46.40),
-> (2, 30.40, 30.40), (3, 37.00, 7.40), (3, -29.60, 0.00),
-> (4, 60.00, 15.40), (4, -10.60, 0.00), (4, -34.00, 0.00),
-> (5, 33.00, 0.00), (5, -25.80, 0.00), (5, 0.00, 7.20),
-> (6, 0.00, 0.00), (6, -51.40, 0.00);
mysql> SELECT i, SUM(d1) AS a, SUM(d2) AS b
-> FROM t1 GROUP BY i HAVING a <> b;
+------+-------+------+
| i | a | b |
+------+-------+------+
| 1 | 21.4 | 21.4 |
| 2 | 76.8 | 76.8 |
| 3 | 7.4 | 7.4 |
| 4 | 15.4 | 15.4 |
| 5 | 7.2 | 7.2 |
| 6 | -51.4 | 0 |
+------+-------+------+
结果是正确的。尽管前5个记录看上去不应能进行比较测试（a和b的值看上去没有什么不同），但它们能进行比较，这是因为显示的数值间的差异在十分位左右，具体情况取决于计算机的体系结构。
如果列d1和d2定义为DECIMAL而不是DOUBLE，SELECT查询的结果仅包含1行，即上面显示的最后1行。
MySQL采用了基于开销的优化器，以确定处理查询的最解方式。在很多情况下，MySQL能够计算最佳的可能查询计划，但在某些情况下，MySQL没有关于数据的足够信息，不得不就数据进行“有教养”的估测。
当MySQL未能做“正确的”事时，可使用下述工具来帮助MySQL：
使用EXPLAIN语句获取关于MySQL如何处理查询的信息。要想使用它，可在SELECT语句前添加关键字EXPLAIN：
mysql> EXPLAIN SELECT * FROM t1, t2 WHERE t1.i = t2.i;
关于EXPLAIN的详细讨论，请参见7.2.1节，“EXPLAIN语法（获取关于SELECT的信息）”。
使用ANALYZE TABLE tbl_name，为已扫描的表更新键分配。请参见13.5.2.1节，“ANALYZE TABLE语法”。
为已扫描的表使用FORCE INDEX，通知MySQL：与使用给定的索引相比，表扫描开销昂贵。请参见13.2.7节，“SELECT语法”。
SELECT * FROM t1, t2 FORCE INDEX (index_for_column)
WHERE t1.col_name=t2.col_name;
USE INDEX和IGNORE INDEX也有一定的帮助。
关于全局和表级别的STRAIGHT_JOIN。请参见13.2.7节，“SELECT语法”。
你可以调节全局或线程类系统变量。例如，用“--max-seeks-for-key=1000”选项启动mysqld，或使用“SET max_seeks_for_key=1000”来通知优化器：假定任何表扫描均不会导致1000个以上的键搜索。请参见5.3.3节，“服务器系统变量”。
ALTER TABLE将表更改为当前字符集。如果在执行ALTER TABLE操作期间遇到重复键错误，原因在于新的字符集将2个键映射到了相同值，或是表已损坏。在后一种情况下，应在表上运行REPAIR TABLE。
如果ALTER TABLE失败并给出下述错误，问题可能是因为在ALTER TABLE操作的早期阶段出现MySQL崩溃，没有名为A-xxx或B-xxx的旧表：
Error on rename of './database/name.frm'
to './database/B-xxx.frm' (Errcode: 17)
在该情况下，进入MySQL数据目录，并删除其名称为以A-或B-开始的所有文件（或许你希望将它们移动到其他地方而不是删除它们）。
ALTER TABLE的工作方式如下：
如果在重命名操作中出错，MySQL将尝试撤销更改。如果错误很严重（尽管这不应出现），MySQL会将旧表保留为B-xxx。简单地在系统级别上重命名表文件，应能使数据复原。
如果在事务性表上使用ALTER TABLE，或正在使用Windows或OS/2操作系统，如果已在表上执行了LOCK TABLE操作，ALTER TABLE将对表执行解锁操作。这是因为InnoDB和这类操作系统不能撤销正在使用的表。
首先，请考虑是否的确需要更改表中的列顺序。SQL的核心要点是从数据存储格式获取应用。总应指定检索数据的顺序。在下面的第1条语句中，以col_name1、col_name2、col_name3顺序返回列；在第2条语句中，以col_name1、col_name3、col_name2顺序返回列：
mysql> SELECT col_name1, col_name2, col_name3 FROM tbl_name;
mysql> SELECT col_name1, col_name3, col_name2 FROM tbl_name;
如果决定更改表列的顺序，可执行下述操作：
mysql> INSERT INTO new_table
-> SELECT columns-in-new-order FROM old_table;
mysql> ALTER TABLE new_table RENAME old_table;
SELECT *十分适合于测试查询。但是，在应用程序中，永远不要依赖SELECT *的使用，不要依赖根据其位置检索列。如果添加、移动或删除了列，所返回的列的顺序和位置不会保持相同。对表结构的简单更改也会导致应用程序失败。
下面介绍了对使用TEMPORARY表的限制：
mysql> SELECT * FROM temp_table, temp_table AS t2;
错误1137：不能再次打开表：'temp_table'
mysql> ALTER TABLE orig_name RENAME new_name;
在本节中，列出了当前MySQL版本中的已知事宜。
关于平台相关事宜的更多信息，请参见2.12节，“具体操作系统相关的注意事项”和附录E：移植到其他系统中的安装和移植说明。
下面列出了已知问题，更正它们具有较高的优先级：
001207 22:07:56 bdb: log_flush: LSN past current end-of-log
如果以特定的方式设计查询，使得数据更改是非决定性（通常不推荐，即使在复制之外也同样），主服务器和从服务器上的数据将变得不同。
例如：
- 将0或NULL值插入AUTO_INCREMENT列中的CREATE ... SELECT或INSERT ... SELECT语句。
- DELETE，如果从具有ON DELETE CASCADE属性的外键的表中删除行。
- REPLACE ... SELECT、INSERT IGNORE ... SELECT，如果在插入的数据中具有重复键。
当且仅当前述查询没有保证决定行顺序的ORDER BY子句时。
例如，对于不具有ORDER BY的INSERT ... SELECT，SELECT可能会以不同的顺序返回行（它会导致具有不同等级的行，从而导致AUTO_INCREMENT列中的不同数值），具体情况取决于优化器在主服务器和从服务器上所作的选择。
在主服务器和从服务器上，查询将进行不同的优化，仅当：
- 使用不同的存储引擎在主服务器上而不是从服务器上保存表。（能够在主服务器和从服务器上使用不同的存储引擎。例如，如果从服务器具有较少的可用磁盘空间，可以在主服务器上使用InnoDB，但在 从服务器桑使用MyISAM）。
- 在主服务器和从服务器上，MySQL缓冲区大小是不同的（key_buffer_size等）。
- 在主服务器和从服务器上运行不同的MySQL版本，版本间的优化器代码也不同。
该问题也会影响使用mysqlbinlog|mysql的数据库恢复。
避免该问题的最简单方法是，为前述的非决定性查询增加ORDER BY子句，以确保总是以相同的顺序保存或更改行。
在将来的MySQL版本中，需要时，我们将自动增加ORDER BY子句。
下面列出了已知的事宜，这些事宜将在恰当的时候更正：
mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1;
mysql> SELECT * FROM temp_table, temp_table AS t2;
错误1137：不能再次打开表：'temp_table'
例如：
SELECT DISTINCT mp3id FROM band_downloads
WHERE userid = 9 ORDER BY id DESC;
以及
SELECT DISTINCT band_downloads.mp3id
FROM band_downloads,band_mp3
WHERE band_downloads.userid = 9
AND band_mp3.id = band_downloads.mp3id
ORDER BY band_downloads.id DESC;
在第2种情况下，使用MySQL服务器3.23.x，可在结果集中获得2个等同行（这是因为，隐藏ID列中的值可能不同）。
注意，在结果集中，仅对不含ORDER BY列的查询才会出现该情况。
这是MySQL参考手册的翻译版本，关于MySQL参考手册，请访问dev.mysql.com。原始参考手册为英文版，与英文版参考手册相比，本翻译版可能不是最新的。