《[计算机软件及应用]MySQL Troubleshooting笔记.doc》由会员分享，可在线阅读，更多相关《[计算机软件及应用]MySQL Troubleshooting笔记.doc（33页珍藏版）》请在三一办公上搜索。
1、MySQL TroubleshootingMySQL Troubleshooting读书笔记目录MySQL Troubleshooting1简介4概要4文章组织架构4CHAPTER 1 Basics5Incorrect Syntax5Wrong Results from a SELECT5When the Problem May Have Been a Previous Update5Getting Information About a Query6Tracing Back Errors in Data6SLOW QUERIES6When the Server Does Not Answer
2、7Issues with Solutions Specific to Storage Engines8Permission Issues8CHAPTER 2 You Are Not Alone: Concurrency Issues9Locks and Transactions9Transaction：9Metadata Locking10How Concurrency Affects Performance10Other Locking Issues10Replication and Concurrency11Effectively Using MySQL Troubleshooting T
3、ools11CHAPTER 3 Effects of Server Options14Service Options14Variables That Are Supposed to Change the Server Behavior14Options That Limit Hardware Resources14Using the -no-defaults Option14Performance Options15Haste Makes Waste15The SET Statement15How to Check Whether Changes Had an Effect15Descript
4、ions of Variables15CHAPTER 4 MySQLs Environment24Physical Hardware Limits24Operating System Limits24Effects of Other Software25CHAPTER 5 Troubleshooting Replication26Displaying Slave Status：26Problems with the I/O Thread26Problems with the SQL Thread27CHAPTER 6 Troubleshooting Techniques and Tools28
5、The Query28Errors and Logs28Information-Gathering Tools29Localizing the Problem (Minimizing the Test Case)30General Steps to Take in Troubleshooting31Testing Methods31Special Testing Tools31Maintenance Tools32CHAPTER 7 Best Practices33Backups33Gathering the Information You Need33Testing33Prevention3
6、3Think About It!33简介概要 Understand the source of a problem, even when the solution is simple. Handle problems that occur when applications run in multiple threads. Debug and fix problems caused by configuration options. Discover how operating system tuning can affect your server. Use troubleshooting
7、techniques specific to replication issues. Get a reference to additional troubleshooting techniques and tools, including third-party solutions. Learn best practices for safe and effective troubleshooting and for preventing problems.文章组织架构如何定位问题原因。最佳方法是利用标准流程定位问题，列出可能的原因，逐个测试。It is very important to
8、identify what the problem is.Chapter 1.Basics介绍了基本的故障排查技巧，几乎适用于任何情况。本章只涵盖了单线程问题，即可通过单一线程重现问题。Chapter 2.You Are Not Alone: Concurrency Issues介绍了多线程应用或者被其他应用的事务干扰时出现的问题。Chapter 3.Effects of Server Options两部分：第一部分是如何调试定位配置选项导致的问题；第二部分是一些重要选项的参考，即需根据需要调整使用。第二部分还包括关于如何解决某些特定选项导致的问题以及如何测试问题是否已被解决的建议和方法。Ch
9、apter 4.MySQLs EnvironmentMySQL运行的硬件及环境的其他方面对MySQL的影响。绝大部分的必要信息指向OS，这通常需要系统管理员协助解决。在此列出一些MySQL DBA需关注的点。Chapter 5.Troubleshooting Replication针对主从场景下产生的问题，针对复制中的特有问题。Chapter 6.Troubleshooting Techniques and Tools介绍了额外的技巧和工具。首先介绍原理，然后介绍一些可用工具。Chapter 7.Best Practices介绍了安全有效地处理故障的良好的习惯和行为。CHAPTER 1 Bas
10、ics基本原则：从最简单的可能原因开始逐步分析。很多情况下，问题是由琐碎的、基础的原因导致的。Incorrect Syntax 故障排查的第一步：语法错误。如拼写错误。应特别MySQL保留字/关键字作为列名的使用。（此类问题很隐蔽，加必要的引号可避免） 应该测试MySQL server端所接收到的SQL语句。（可确保server端执行的语句符合预期） 程序的输出功能（如PHP的echo函数）和general log可以帮助你快速获取SQL语句示例：SELECT id FROM t1 WHERE accessible=1;5.1后accessible为保留字PHP代码$query = SELEC
11、T * FROM t4 WHERE f1 IN(;for ($i = 1; $i 101; $i +)$query .= row$i,; #$query .= row$i,;（输出QUERY语句，echo函数）$query = rtrim($query, ,);$query .= );$result = mysql_query($query);并非总是可以使用输出函数，如程序利用编译语言中第三方类库生成SQL语句、或调用提供CRUD接口的类、或者用指定参数测试特定语句时不希望用户看到QUERY语句。此时，便可借助general log。MySQL 5.1之后可动态开启/关闭。SET GLOBA
12、L general_log = on; #开启general logSET GLOBAL log_output = table; #将查询记录到表中Wrong Results from a SELECT两种情况：SELECT语句问题或者DB中数据不同于预期。 如果SELECT未能按预期执行，则将其拆分成小块，然后单独分析每一块。 EXPLAIN EXTENDED后执行SHOW WARNINGS可以获取到语句是怎么被优化和执行的。 当怀疑语句的执行行为时，可以从MySQL BUG列表中查找相关信息。When the Problem May Have Been a Previous Update当
13、结果集不符合你的查询预期时，也有可能是之前并没有INSERT/UPDATE/DELETE相关数据。也有可能是备份延迟、同步延迟引起的数据的不一致。在应用中应该显示地检查一些信息函数，比如DML操作所影响的行数。 将UPDATE/DELETE操作可以转换为具有相同的JOIN和WHERE条件的SELECT语句，来查看满足操作条件的行信息，并且不会影响到表中实际记录。UPDATE table_name SET col1= and col2=;#该语句可以执行，但是执行结果不符合预期不正确，实际执行次序为UPDATE table_name SET col1 = ( and col2=); Gettin
14、g Information About a QueryMySQL中支持的供获取QUERY信息的函数。（API函数）mysql_affected_rows()返回影响的行的函数。-1表示语句错误，0表示未有变更client_found_rows()WHERE条件匹配的行数mysql_num_rows()返回结果集中行的数目mysql_info()MySQL的执行信息。对于UPDATE，输出是：Rows matched: # Changed: # Warnings: #mysql_warning_count()获取warnings的个数mysql_sqlstate()SQL的状态信息。如“4200
15、0”：语法错误；“00000”：没有error和warningmysql_errno()返回error的编号mysql_error()返回error的详细信息perror组件工具：解释错误编号的含义Tracing Back Errors in Data利用临时表来暂存其他查询的结果集，然后在其上做一些变更或查询，可以避免一些误操作及阻塞其他应用。主从下数据库不一致产生的原因：主库插入了错误的数据或复制过程中数据被毁坏。 当确认语句没问题时，应该检查在之前应用做了哪些操作，从而导致了数据不符合预期。SLOW QUERIES语句、表结构以及server优化。Tuning a Query with
16、Information from EXPLAINEXPLAIN中：type（联接类型）、rows（MySQL认为执行查询时必须检查的行数，约数）阅读EXPLAIN的信息，并且将当前计划和你所想达到的计划做出对比，然后优化调整。语句优化针对特定的数据集合。Table Tuning and Indexes尽量少使用IGNORE INDEX和FORCE INDEX，除非版本每次升级时及随数据量的增长都去重新检查这些语句。When to Stop Optimizing：有进有退适可而止首先，知道QUERY是做什么用的；其次，查看EXPLAIN中联接类型type列，但应牢记自己的数据情况；不要仅仅依赖E
17、XPLAIN，还应该确保实际执行时间；应着眼于应用的整体性能，而非单个语句。Effects of Options缓冲区大小Swapping：大的缓冲区可能会导致操作系统级别的swap操作导致低性能，取决于系统内存大小。MySQL所需缓冲区大小小于物理内存时，性能比较好。Startup time：buffer越大启动越慢。Stale data：多线程之间共享缓存导致内存碎片问题，进而导致server突然运行缓慢。关注性能参数的同时也应注意高可用，切不可为性能调整而导致MySQL事务安全性等的下降。Queries That Modify Data对比语句执行先后系统状态参数Handler_%可以检
18、查是否使用了INDEX。（SHOW STATUS = SHOW SESSION STATUS，累积值）Handler_read_rnd_next：在数据文件中读下一行的请求数。值比较高意味着表索引不正确或写入的查询没有利用索引，以至于进行扫描。Handle_read_key：读请求中利用索引的次数。对于INSERT的优化，主要是从系统选项入手。（提高INSERT的一个小技巧：一次COMMIT多条记录） Keep the performance of the whole application in mind while tuning any single query.No Silver Bul
19、let“混合”模式：首先调整server选项，尤其是关注针对所用存储引擎相关的选项，然后调整QUERIES；当主要语句被调整后，再次考虑server选项。如此反复。用性能调优中的众多信息来建立自己的优化策略。When the Server Does Not Answer“Lost connection to server during query”及“Server has gone away”，两个原因：server issues（极可能crash）和连接选项的误用（timeout选项及max_allowed_packet）可以从进程状态监视器中获知server是否crash。如error文件
20、 对于未知的错误，首要任务是检查ERROR文件。根据error文件中的信息，去开发环境中重现问题 查询MySQL的BUG列表，寻求解决方案；下载MySQL新版本，重试问题查询。crash可能由特定语句触发，也可能由运行环境引起。最有可能是可用内存的缺少。Issues with Solutions Specific to Storage Engines存储引擎经常遇到的问题是CORRUPTION，通常由磁盘、系统或MySQL server的crash导致。修复表之前应该备份表文件，以便回退。MyISAM Corruption三个文件：table_name.frm、table_name.MYD和t
21、able_name.MYI。不带参数的CHECK TABLE将列出当前表的状态。CHECT TABLE table_name; REPAIR TABLE table_name;如果REPAIR TABLE不起作用，可以使用REPAIR TABLE EXTENDED（很慢）或REPAIR TABLE USE_FRM（将删除索引文件，然后按.frm文件重建，数据来自于.MYD文件。）可用的工具还有：myisamchk和mysqlcheck。myisamchk直接访问数据文件而不需要MySQL运行。独占访问表文件，所以尽量避免运行时使用。（一些有用的选项：-safe-recover、-extend-
22、check、-sort-recover、-description、-verbose）$myisamchk -backup -recover t2InnoDB Corruption-innodb_file_per_table，按表创建数据文件。一般，启动时自动恢复。若修复不成功，-innodb_force_recovery（0-6，6个级别）遇到不能自动修复的情况，使用-innodb_force_recovery，从1到6依次尝试，直到可以启动server进行查询。利用SELECT INTO OUTFILE将表中数据DUMP，利用DROP和CREATE重建表，最后-innodb_force_re
23、covery=0启动server并加载DUMP文件。mysqlbackup -copy-back即InnoDB HotBackupPermission Issues 本应该有权限连接DB的用户不能连接，本无权限的可以连接 可以连接server，但没有相关的对象权限，或者对象权限是多余的。 连接不到server。（需要根据提示信息来查找原因）MySQL sorts rows in this table from the most specific to the least specific host value and uses the first value found. USER() and
24、 CURRENT_USER(), together with the query SELECT user, host FROM mysql.user ORDER BY host DESC, are the first resort in case of a permission issue.CHAPTER 2 You Are Not Alone: Concurrency Issues并发问题的一个症状是优化的查询突然变慢。变慢不是持续发生的，但实际上一些随机的事件或许暗示你应该去检查并发性问题。并发同样会影响到SLAVE上SQL线程。SHOW PROCESSLIST来检查并发线程运行情况。Lo
25、cks and Transactions可在server层级和存储引擎层级设置锁。四种：表锁、行锁、页锁（仅BDB引擎）和元数据锁（5.5新特性，锁定SCHEMA信息，避免多重语句的事务访问一个表时被其他线程更改了表结构或者删除表）Table Locks：MyISAM引擎，或显式调用LOCK TABLES或5.5之前版本的DDL操作。Row Locks：通常设置在存储引擎上。行锁机制是比较复杂的，某种情况下会进行锁升级。例如在未有UNIQUE索引的列上进行WHERE条件查询时，则会上升为表锁，因为存储引擎不知道是否会有其他线程来更改相同的行。SHOW ENGINE INNODB STATUS行
26、锁的应用将提升并发性进而增强了整个应用的性能。Transaction：Hidden Queries：通过SHOW ENGINE INNODB STATUS查看锁情况后，查找相关语句。还可通过InnoDB监视器以及（仅对InnoDB Plugin有效，INFORMATION_SCHEMA中的INNODB_LOCKS / INNODB_LOCK_WAITS / INNODB_TRX表） 未提交的事务会导致记录被锁，直到COMMIT/ROLLBACK或者语句被KILL。因此，对于多语句的事务处理，应就尽快提交。即使语句不修改任何行，也会导致锁问题。SET AUTOCOMMIT = 0;BEGIN;
27、/ START TRANSACTION; （会导致autocommit=0）Deadlocks：行锁情况下不可避免。InnoDB内部有死锁监控机制。发现死锁后，会回滚其中一个事务，然后返回error信息。应用设计中，也应该对此情况有类似准备并妥善处理回滚。SHOW ENGING INNODB STATUS中包括死锁信息，需特别注意WAITING FOR THIS LOCK TO BE GRANTED（显示事务在等待哪个锁）部分以及HOLDS THE LOCK(S)（显示阻塞事务的锁）Implicit Commits：如DDL、事务相关、管理语句会导致隐式提交。隐式提交可能会导致的一种情况是：一
28、些本应被回滚的语句被错误地提交了。示例：CREATE TABLE t1(f1 INT) ENGINE=InnoDB;BEGIN;INSERT INTO t1 VALUES(100);CREATE TABLE t2 LIKE t1;INSERT INTO t1 VALUES(200);ROLLBACK;t1表中有100，而200被回滚了。一般来讲，应使语句尽可能小，这样即使因失误而导致隐式提交，也可保证影响面最小化。Metadata LockingMySQL 5.5.3之后，DDL操作会被使用元数据锁，以防止在并发情况下影响到其他事务操作。元数据锁独立于存储引擎。SHOW PROCESSLIST
29、时，会看到“Waiting for table metadata lock”How Concurrency Affects Performance当应用可以创建多个MySQL连接时，应该考虑到线程并行和竞争的可能性。性能问题很难被发现，只有通过SLOW QUERY或者用户反映来获知。当一个查询突然变慢，首先应确认该语句已经被合理优化（可到其他环境去测试验证）。重现问题场景是最难的一步。Monitoring InnoDB Transactions for Concurrency ProblemsInnoDB监视器。MySQL客户端命令行中-A选项在调试并发相关问题时非常有用。Monitoring
30、 Other Resources for Concurrency ProblemsSHOW PROCESSLIST或SELECT col_name FROM INFORMATION_SCHEMA.PROCESSLIST;，然后定期输出到文件或者相关表中。有些资源是线程独有的，即只在需要时分配给特定操作；有些则是共享的，如内部的缓存。同时应该考虑到操作系统方面的限制。一般，分配的内存越多，线程运行越快。内存是单个线程独有的，但单线程内存分配越多，可同时运行的线程数目就越少。应寻求高性能和物理内存实际使用量之间的平衡点。分配给特定操作的资源同样是有限的。折中：将大量的资源分配给真正需要大缓存的会话
31、/连接，而其他使用默认值。第三种资源可被所有线程共享，通常为内部缓存。一个潜在问题：数据的更改会导致缓存数据的失效，进而使得其后的查询需要很多时间。Cache很大时，失效过程会消耗很长时间。操作资源的限制同样会影响到性能，如文件操作符、CPU资源等。如文件描述符限制了服务器上连接数目、可同时打开的表的数目甚至一个表上分区的数目。Other Locking Issues内部锁和执行特定操作时的互斥请求也会影响到应用。主要为保护数据完整性。PERFORMANCE_SCHEMA.mutex_instances：记录了server启动以来所有的互斥量。只需查询where LOCKED_BY_THREA
32、D_ID is not null的记录，以过滤非实时的情况。PERFORMANCE_SCHEMA.events_waits_current：可查询who在等待互斥量。该表中的THREAD_ID是mysqld内部分配给线程的真实编号，而不是connection thread的编号。PERFORMANCE_SCHEMA.threads：查找connection thread，可帮助进一步获取导致死锁的语句。应关注于一个正常操作上的长时间的信号量等待。Replication and ConcurrencyMASTER为多线程的，而SLAVE是单线程的，会影响到复制性能和一致性。从MySQL5.1，三
33、种binlog方式：statement-based、row-based及mixed-based。row-based会在binlog中记录原始数据，SLAVE并不执行和MASTER一样的语句而是直接替换行记录内容。MySQL参考手册上列出了在语句级别复制时可能会导致出错的语句清单。MySQL High Availability中详细介绍了复制中的一致性问题。binlog记录的次序可能不同于语句在server上的执行顺序，binlog是COMMIT/ROLLBACK时记录语句，而非BEGIN/START TRANSACTION的时间。这个机制有导致SLAVE执行顺序和MASTER上执行顺序不一致的
34、风险，出现数据不一致。（SLAVE多线程复制方式无法避免数据一致性问题）UPDATE LIMIT语句不是安全的语句，非事务型存储引擎在使用INSERT DELAYED时，同样可能会出现顺序问题。执行顺序和log顺序问题应该在应用设计时给予足够关注。Mixing Transactional and Nontransactional Tables在同一事务中不要混合事务表和非事务性表。非事务性表上的更改首先会被放在事务缓存里面，直到事务结束时被记录到binlog中，但其已对表中数据产生影响。（同样地，在同一事务中，也不要混合使用不同引擎的事务表）如果必须混合事务性表和非事务性表，则应该使用其他锁机
35、制，比如LOCK TABLE，来确保rollback或者crash后数据的一致性问题。binlog_direct_non_transactional_updates：可以控制非事务表上的更新操作什么时候被写入到binlog。使用row-based或者mixed-based的binlog方式可以解决绝大数复制相关的问题，不过对于MASTER上数据不符合预期则并没有帮助。Issues on the SlaveSLAVE上SQL线程是由SYSTEM USER运行。Effectively Using MySQL Troubleshooting ToolsSHOW FULL PROCESSLIST 及
36、INFORMATION_SCHEMA.PROCESSLIST表（MySQL 5.1之后）。SHOW PROCESSLIST并不能揭示多语句事务之间的关系，但可发现问题的一些症状。比如Sleep很久。相对于PROCESSLIST表，SHOW PROCESSLIST更通用。SHOW ENGINE INNODB STATUS and InnoDB MonitorsSHOW ENGINE INNODB STATUS，跟并发相关的：SEMAPHORES，LATEST DETECTED DEADLOCK和TRANSACTIONS。SEMAPHORES包含等待互斥量或rw-lock信号的线程信息。应关注于等
37、待线程的数量以及长时间等待的线程。LATEST DETECTED DEADLOCK包含最近检测到的死锁信息。TRANSACTION包含当前运行的所有事务信息。应重点关注该部分的锁信息。InnoDB监视器可以将信息输入到错误日志文件中。还可看到FILE I/O，INSERT BUFFER AND ADAPTIVE HASH INDEX，BUFFER POOL AND MEMORY及ROW OPERATIONS等信息。INFORMATION_SCHEMA TablesMySQL 5.1增加了InnoDB相关的表：INNODB_TRX（当前运行的事务列表）、INNODB_LOCKS（事务持有及等待的
38、锁信息）及INNODB_LOCK_WAITS（事务等待的锁信息）调试并发问题时典型的INFORMATION_SCHEMA查询语句事务等待的所有锁信息：SELECT * FROM INNODB_LOCK_WAITS;阻塞事务列表SELECT * FROM INNODB_LOCKS WHERE LOCK_TRX_ID IN (SELECT BLOCKING_TRX_ID FROM INNODB_LOCK_WAITS); SELECT INNODB_LOCKS.* FROM INNODB_LOCKS JOIN INNODB_LOCK_WAITS ON ( INNODB_LOCKS.LOCK_TRX_
39、ID = INNODB_LOCK_WAITS.BLOCKING_TRX_ID);等待锁的事务列表SELECT TRX_ID, TRX_REQUESTED_LOCK_ID, TRX_MYSQL_THREAD_ID, TRX_QUERY FROM INNODB_TRX WHERE TRX_STATE = LOCK WAIT;PERFORMANCE_SCHEMA TablesPERFORMANCE_SCHEMA存储引擎并不持久化存储表。并发相关表：COND_INSTANCES、FILE_INSTANCES、MUTEX_INSTANCES、RWLOCK_INSTANCES及各种EVENTS_WAITS
40、_*表。THREADS表有助于将内部线程和MySQL用户线程关联起来。*INSTANCES表都包含NAME（实例名称）和OBJECT_INSTANCE_BEGIN（对象相对应的内存地址）字段。COND_INSTANCES包含server启动后产生的一系列等待情况。FILE_INSTANCES记录了一系列可以被performance schema看到的文件。当文件首次被打开时，文件名会被记录到表中，直到被从磁盘删除。当前被打开的文件有OPEN_COUNT，该字段包含当前所用该文件的句柄数。MUTEX_INSTANCES包含一系列互斥量。当前被锁的互斥量均符合WHERE LOCKED_BY_THR
41、EAD_ID IS NOT NULL条件。RWLOCK_INSTANCES则包含了所有的读/写锁事件。WRITE_LOCKED_BY_THREAD_ID持有锁的线程ID；READ_LOCKED_BY_COUNT当前请求读锁的线程数目。EVENTS_WAITS_*则包含各线程等待事件的信息。THREADS表：包含了当前在运行的所有线程。ID是内部分配的，完全不同于连接线程ID。PROCESS_LIST_ID字段为连接线程ID，其和每个特定线程相关联的。*_SUMMARY_*表：终止事件的汇总信息。Log FilesError-log和general-log。错误日志信息包含出错信息、不安全的同步
42、语句、长时间信号等待之后的内部crash事件等。遇到问题时，应首先检查该文件。一个典型的故障排查模式是：查询InnoDB监视器输出，获取极有可能阻塞其他事务的事务MySQL线程ID，然后执行下面语句：SELECT argument, event_time FROM mysql.general_log WHERE thread_id = THIS_THREAD_ID ORDER BY event_time;返回一系列阻塞线程所执行的查询。从中可以找到开始整个多语句事务的开始语句。CHAPTER 3 Effects of Server Options多种途径对选项参数进行设置：f配置文件、启动se
43、rver时命令行或运行时设置变量。MySQL里面通常：options由连词符表示（variable-name），而相应的variables由下划线表示（variable_name）。通常MySQL命令行和配置文件支持两种语法，不过对于变量只使用variable_name。Service Options两类典型的情况：选项指向了错误的路径、当一个特定属性被打开后改变了mysqld命令的行为。指定了错误的路径启动时，mysqld会产生错误信息；但是如果是通过系统守护进程启动，则会在首次连接时显示“ERROR 2002 (HY000): Cant connect to local MySQL ser
44、ver through socket .”，然后需要查看错误日志文件或者OS日志。mysqladmin工具有ping命令可以判断MySQL server是否存活。有些路径选项并不会影响mysqld正常启动，但是错误的指向会导致特定功能的失效。当发现所需要的某个属性不存在时，应该首先检查error logfile。理解所需特征如何影响server工作是非常重要的。例：InnoDB不可用时，若sql_mode没有包含NO_ENGINE_SUBSTITUTION（指定后，可以防止当需要的存储引擎被禁用或未编译时被自动替换为默认存储引擎），则创建语句依然成功执行（会有WARNINGS），不过表类型为默
45、认存储引擎。检查WARNINGS信息是很好的习惯。当遇到跟所依赖的特性相关的问题时，应检查其是否在server实例中存在。选项会影响到server行为，即使其主要目的不是如此。比如，binlog的开启会导致存储函数的创建发生一些变化。Variables That Are Supposed to Change the Server Behavior另一组变量将影响MySQL server如何处理用户输入。如sql_mode中STRICT_TRANS_TABLES同样会影响到非事务性表。当MySQL server行为不符合预期时，应仔细检查选项。Options That Limit Hardwar
46、e Resources两个目的：调整性能和限制特定操作的资源使用。如限制server与client间的流量、阻止拒绝服务攻击等。这些变量的调整同样可能导致不同的或非预期的行为。如经常被忽略的MAX_ALLOWED_PACKET。当对于正确的查询返回语法错误时，应检查MAX_ALLOWED_PACKET的大小。Using the -no-defaults Option比较全部默认选项运行mysql（启动时指定-no-defaults）与指定选项运行mysql两者之间的差异，来进行故障排查。（-no-defaults及-defaults-file选项在mysqld启动时，必须放置在第一位，否则无效）Performance Options一般不会导致错误，但会对性能有显著影响。然而，有一种情形：这样的选项会导致error，将其从配置文件中移除或调小其值是有意义的。当遇到资源之外的错误时发生，通常跟内存或者文件描述符的缺失有关。Haste Makes Waste欲速则不达除非100%确定哪里出错，否则逐步增加选项，然后每次都测试配置，同时应记录每次测试结果。（最为稳妥的方法）The SET StatementSESSION/GLOBAL级别。GLOB
