©
Dokumen ini menggunakan Manual laman web PHP Cina Lepaskan
目录
本章包含许多在你处理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。原始参考手册为英文版,与英文版参考手册相比,本翻译版可能不是最新的。