MySQL是一个小型关系型数据库管理系统，开发者为瑞典MySQL AB公司，现在已经被Sun公司收购，支持FreeBSD、Linux、MAC、Windows等多种操作系统与其他的大型数据库例如Oracle、DB2、SQL Server等相比功能稍弱一些 1、可以处理拥有上千万条记录的大型数据 2、支持常见的SQL语句规范 3、可移植行高，安装简单小巧 4、良好的运行效率，有丰富信息的网络支持 5、调试、管理，优化简单（相对其他大型数据库）
Char是一种固定长度的类型，varchar是一种可变长度的类型
隔离性、持续性、一致性、原子性
SQL标准定义的四个隔离级别为： read uncommited：读取未提交内容 read committed：读取提交内容 repeatable read：可重读 serializable：可串行化 详细解释如下： Read Uncommitted（读取未提交内容） 在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。 Read Committed（读取提交内容） 这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。 Repeatable Read（可重读） 这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读（Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control 间隙锁）机制解决了该问题。注：其实多版本只是解决不可重复读问题，而加上间隙锁（也就是它这里所谓的并发控制）才解决了幻读问题。 Serializable（可串行化） 这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。 对于不同的事务，采用不同的隔离级别分别有不同的结果。不同的隔离级别有不同的现象。主要有下面3种现在： 1、脏读（dirty read）：一个事务可以读取另一个尚未提交事务的修改数据。 2、非重复读（nonrepeatable read）：在同一个事务中，同一个查询在T1时间读取某一行，在T2时间重新读取这一行时候，这一行的数据已经发生修改，可能被更新了（update），也可能被删除了（delete）。 3、幻像读（phantom read）：在同一事务中，同一查询多次进行时候，由于其他插入操作（insert）的事务提交，导致每次返回不同的结果集。 不同的隔离级别有不同的现象，并有不同的锁定/并发机制，隔离级别越高，数据库的并发性就越差，4种事务隔离级别分别表现的现象如下表：
1、MySQL的复制原理以及流程
基本原理流程，3个线程以及之间的关联；
1. 主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中；
2. 从：io线程——在使用start slave 之后，负责从master上拉取 binlog 内容，放进 自己的relay log中；
3. 从：sql执行线程——执行relay log中的语句；
2、MySQL中myisam与innodb的区别，至少5点
(1)、问5点不同；
1>.InnoDB支持事物，而MyISAM不支持事物
2>.InnoDB支持行级锁，而MyISAM支持表级锁
3>.InnoDB支持MVCC, 而MyISAM不支持
4>.InnoDB支持外键，而MyISAM不支持
5>.InnoDB不支持全文索引，而MyISAM支持。
(2)、innodb引擎的4大特性
插入缓冲（insert buffer),二次写(double write),自适应哈希索引(ahi),预读(read ahead)
(3)、2者selectcount(*)哪个更快，为什么
myisam更快，因为myisam内部维护了一个计数器，可以直接调取。
3、MySQL中varchar与char的区别以及varchar(50)中的50代表的涵义 (1)、varchar与char的区别 char是一种固定长度的类型，varchar则是一种可变长度的类型 (2)、varchar(50)中50的涵义 最多存放50个字符，varchar(50)和(200)存储hello所占空间一样，但后者在排序时会消耗更多内存，因为order by col采用fixed_length计算col长度(memory引擎也一样) (3)、int（20）中20的涵义 是指显示字符的长度 但要加参数的，最大为255，比如它是记录行数的id,插入10笔资料，它就显示00000000001 ~~~00000000010，当字符的位数超过11,它也只显示11位，如果你没有加那个让它未满11位就前面加0的参数，它不会在前面加0 20表示最大显示宽度为20，但仍占4字节存储，存储范围不变； (4)、mysql为什么这么设计 对大多数应用没有意义，只是规定一些工具用来显示字符的个数；int(1)和int(20)存储和计算均一样； 4、问了innodb的事务与日志的实现方式 (1)、有多少种日志； 错误日志：记录出错信息，也记录一些警告信息或者正确的信息。 查询日志：记录所有对数据库请求的信息，不论这些请求是否得到了正确的执行。 慢查询日志：设置一个阈值，将运行时间超过该值的所有SQL语句都记录到慢查询的日志文件中。 二进制日志：记录对数据库执行更改的所有操作。 中继日志： 事务日志： (2)、事物的4种隔离级别 隔离级别 读未提交(RU) 读已提交(RC) 可重复读(RR) 串行 (3)、事务是如何通过日志来实现的，说得越深入越好。 事务日志是通过redo和innodb的存储引擎日志缓冲（Innodb log buffer）来实现的，当开始一个事务的时候，会记录该事务的lsn(log sequence number)号; 当事务执行时，会往InnoDB存储引擎的日志 的日志缓存里面插入事务日志；当事务提交时，必须将存储引擎的日志缓冲写入磁盘（通过innodb_flush_log_at_trx_commit来控制），也就是写数据前，需要先写日志。这种方式称为“预写日志方式” 5、问了MySQL binlog的几种日志录入格式以及区别 (1)、binlog的日志格式的种类和分别 (2)、适用场景； (3)、结合第一个问题，每一种日志格式在复制中的优劣。 Statement：每一条会修改数据的sql都会记录在binlog中。 优点：不需要记录每一行的变化，减少了binlog日志量，节约了IO，提高性能。(相比row能节约多少性能 与日志量，这个取决于应用的SQL情况，正常同一条记录修改或者插入row格式所产生的日志量还小于Statement产生的日志量，但是考虑到如果带条 件的update操作，以及整表删除，alter表等操作，ROW格式会产生大量日志，因此在考虑是否使用ROW格式日志时应该跟据应用的实际情况，其所 产生的日志量会增加多少，以及带来的IO性能问题。) 缺点：由于记录的只是执行语句，为了这些语句能在slave上正确运行，因此还必须记录每条语句在执行的时候的 一些相关信息，以保证所有语句能在slave得到和在master端执行时候相同 的结果。另外mysql 的复制,像一些特定函数功能，slave可与master上要保持一致会有很多相关问题(如sleep()函数， last_insert_id()，以及user-defined functions(udf)会出现问题). 使用以下函数的语句也无法被复制： * LOAD_FILE() * UUID() * USER() * FOUND_ROWS() * SYSDATE() (除非启动时启用了 --sysdate-is-now 选项) 同时在INSERT ...SELECT 会产生比 RBR 更多的行级锁 2.Row:不记录sql语句上下文相关信息，仅保存哪条记录被修改。 优点： binlog中可以不记录执行的sql语句的上下文相关的信息，仅需要记录那一条记录被修改成什么了。所以rowlevel的日志内容会非常清楚的记录下 每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题 缺点:所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容,比 如一条update语句，修改多条记录，则binlog中每一条修改都会有记录，这样造成binlog日志量会很大，特别是当执行alter table之类的语句的时候，由于表结构修改，每条记录都发生改变，那么该表每一条记录都会记录到日志中。 3.Mixedlevel: 是以上两种level的混合使用，一般的语句修改使用statment格式保存binlog，如一些函数，statement无法完成主从复制的操作，则 采用row格式保存binlog,MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，也就是在Statement和Row之间选择 一种.新版本的MySQL中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录。至于update或者delete等修改数据的语句，还是会记录所有行的 变更。 6、问了下MySQL数据库cpu飙升到500%的话他怎么处理？ (1)、没有经验的，可以不问； (2)、有经验的，问他们的处理思路。 列出所有进程 show processlist 观察所有进程 多秒没有状态变化的(干掉) 查看超时日志或者错误日志 (做了几年开发,一般会是查询以及大批量的插入会导致cpu与i/o上涨,,,,当然不排除网络状态突然断了,,导致一个请求服务器只接受到一半，比如where子句或分页子句没有发送,,当然的一次被坑经历) 7、sql优化 (1)、explain出来的各种item的意义； select_type 表示查询中每个select子句的类型 type 表示MySQL在表中找到所需行的方式，又称“访问类型” possible_keys 指出MySQL能使用哪个索引在表中找到行，查询涉及到的字段上若存在索引，则该索引将被列出，但不一定被查询使用 key 显示MySQL在查询中实际使用的索引，若没有使用索引，显示为NULL key_len 表示索引中使用的字节数，可通过该列计算查询中使用的索引的长度 ref 表示上述表的连接匹配条件，即哪些列或常量被用于查找索引列上的值 Extra 包含不适合在其他列中显示但十分重要的额外信息 (2)、profile的意义以及使用场景； 查询到 SQL 会执行多少时间, 并看出 CPU/Memory 使用量, 执行过程中 Systemlock, Table lock 花多少时间等等 8、备份计划，mysqldump以及xtranbackup的实现原理 (1)、备份计划； 这里每个公司都不一样，您别说那种1小时1全备什么的就行 (2)、备份恢复时间； 这里跟机器，尤其是硬盘的速率有关系，以下列举几个仅供参考 20G的2分钟（mysqldump） 80G的30分钟(mysqldump) 111G的30分钟（mysqldump) 288G的3小时（xtra) 3T的4小时（xtra) 逻辑导入时间一般是备份时间的5倍以上 (3)、xtrabackup实现原理 在InnoDB内部会维护一个redo日志文件，我们也可以叫做事务日志文件。事务日志会存储每一个InnoDB表数据的记录修改。当InnoDB启动时，InnoDB会检查数据文件和事务日志，并执行两个步骤：它应用（前滚）已经提交的事务日志到数据文件，并将修改过但没有提交的数据进行回滚操作。 9、mysqldump中备份出来的sql，如果我想sql文件中，一行只有一个insert....value()的话，怎么办？如果备份需要带上master的复制点信息怎么办？ --skip-extended-insert [root@helei-zhuanshu ~]# mysqldump -uroot -p helei --skip-extended-insert Enter password: KEY `idx_c1` (`c1`), KEY `idx_c2` (`c2`) ) ENGINE=InnoDB AUTO_INCREMENT=51 DEFAULT CHARSET=latin1; /*!40101 SET character_set_client = @saved_cs_client */; -- -- Dumping data for table `helei` -- LOCK TABLES `helei` WRITE; /*!40000 ALTER TABLE `helei` DISABLE KEYS */; INSERT INTO `helei` VALUES (1,32,37,38,'2016-10-18 06:19:24','susususususususususususu'); INSERT INTO `helei` VALUES (2,37,46,21,'2016-10-18 06:19:24','susususususu'); INSERT INTO `helei` VALUES (3,21,5,14,'2016-10-18 06:19:24','susu'); 10、500台db，在最快时间之内重启 puppet，dsh 11、innodb的读写参数优化 (1)、读取参数 global buffer pool以及 local buffer； (2)、写入参数； innodb_flush_log_at_trx_commit innodb_buffer_pool_size (3)、与IO相关的参数； innodb_write_io_threads = 8 innodb_read_io_threads = 8 innodb_thread_concurrency = 0 (4)、缓存参数以及缓存的适用场景。 query cache/query_cache_type 并不是所有表都适合使用query cache。造成query cache失效的原因主要是相应的table发生了变更
· 第一个：读操作多的话看看比例，简单来说，如果是用户清单表，或者说是数据比例比较固定，比如说商品列表，是可以打开的，前提是这些库比较集中，数据库中的实务比较小。
· 第二个：我们“行骗”的时候，比如说我们竞标的时候压测，把query cache打开，还是能收到qps激增的效果，当然前提示前端的连接池什么的都配置一样。大部分情况下如果写入的居多，访问量并不多，那么就不要打开，例如社交网站的，10%的人产生内容，其余的90%都在消费，打开还是效果很好的，但是你如果是qq消息，或者聊天，那就很要命。
· 第三个：小网站或者没有高并发的无所谓，高并发下，会看到 很多 qcache 锁 等待，所以一般高并发下，不建议打开query cache
12、你是如何监控你们的数据库的？你们的慢日志都是怎么查询的？ 监控的工具有很多，例如zabbix，lepus，我这里用的是lepus 13、你是否做过主从一致性校验，如果有，怎么做的，如果没有，你打算怎么做？ 主从一致性校验有多种工具 例如checksum、mysqldiff、pt-table-checksum等 14、你们数据库是否支持emoji表情，如果不支持，如何操作？ 如果是utf8字符集的话，需要升级至utf8_mb4方可支持 15、你是如何维护数据库的数据字典的？ 这个大家维护的方法都不同，我一般是直接在生产库进行注释，利用工具导出成excel方便流通。 16、你们是否有开发规范，如果有，如何执行的 有，开发规范网上有很多了，可以自己看看总结下 17、表中有大字段X(例如：text类型)，且字段X不会经常更新，以读为为主，请问 (1)、您是选择拆成子表，还是继续放一起； (2)、写出您这样选择的理由。 答：拆带来的问题：连接消耗 + 存储拆分空间；不拆可能带来的问题：查询性能； 如果能容忍拆分带来的空间问题,拆的话最好和经常要查询的表的主键在物理结构上放置在一起(分区) 顺序IO,减少连接消耗,最后这是一个文本列再加上一个全文索引来尽量抵消连接消耗 如果能容忍不拆分带来的查询性能损失的话:上面的方案在某个极致条件下肯定会出现问题,那么不拆就是最好的选择 18、MySQL中InnoDB引擎的行锁是通过加在什么上完成(或称实现)的？为什么是这样子的？ 答：InnoDB是基于索引来完成行锁 例: select * from tab_with_index where id = 1 for update; for update 可以根据条件来完成行锁锁定,并且 id 是有索引键的列, 如果 id 不是索引键那么InnoDB将完成表锁,,并发将无从谈起
开放性问题：据说是腾讯的 一个6亿的表a，一个3亿的表b，通过外间tid关联，你如何最快的查询出满足条件的第50000到第50200中的这200条数据记录。 1、如果A表TID是自增长,并且是连续的,B表的ID为索引 select * from a,b where a.tid = b.id and a.tid>500000 limit 200; 2、如果A表的TID不是连续的,那么就需要使用覆盖索引.TID要么是主键,要么是辅助索引,B表ID也需要有索引。 select * from b , (select tid from a limit 50000,200) a where b.id = a .tid;
2、 通过HandlerMapping查找Handler
3、 返回执行链
a) Handler对象
b) 拦截器数组（list）
4、 通过适配器对Handler对象进行包装，调用Handler
5、 处理用户的请求
6、 返回ModelAndView对象
a) Model数据
b) 视图名称，不是真正的视图对象
7、 将ModelAndView对象返回到前端控制器
8、 通过视图名称在视图解析器中查找视图对象
9、 返回真正的视图对象
10、 前端控制器拥有了模型数据和视图对象，进行视图渲染
11、 返回渲染后的视图
12、 给用户产生响应
l 了解什么是优化
l 掌握优化查询的方法
l 掌握优化数据库结构的方法
l 掌握优化MySQL服务器的方法
l 合理安排资源、调整系统参数使MySQL运行更快、更节省资源。
l 优化是多方面的，包括查询、更新、服务器等。
l 原则：减少系统瓶颈，减少资源占用，增加系统的反应速度。
l 使用SHOW STATUS语句查看MySQL数据库的性能参数
• SHOW STATUS LIKE 'value‘
l 常用的参数：
• Slow_queries 慢查询次数
• Com_(CRUD) 操作的次数
• Uptime 上线时间
在MySQL中可以使用EXPLAIN查看SQL执行计划，用法：EXPLAIN SELECT * FROM tb_item
SELECT识别符。这是SELECT查询序列号。这个不重要。
表示SELECT语句的类型。
有以下几种值：
1、 SIMPLE 表示简单查询，其中不包含连接查询和子查询。
2、 PRIMARY 表示主查询，或者是最外面的查询语句。
3、 UNION 表示连接查询的第2个或后面的查询语句。
4、 DEPENDENT UNION UNION中的第二个或后面的SELECT语句，取决于外面的查询。
5、 UNION RESULT 连接查询的结果。
6、 SUBQUERY 子查询中的第1个SELECT语句。
7、 DEPENDENT SUBQUERY 子查询中的第1个SELECT语句，取决于外面的查询。
8、 DERIVED SELECT(FROM 子句的子查询)。
表示查询的表。
表示表的连接类型。
以下的连接类型的顺序是从最佳类型到最差类型：
1、 system 表仅有一行，这是const类型的特列，平时不会出现，这个也可以忽略不计。
2、 const 数据表最多只有一个匹配行，因为只匹配一行数据，所以很快，常用于PRIMARY KEY或者UNIQUE索引的查询，可理解为const是最优化的。
3、 eq_ref mysql手册是这样说的:"对于每个来自于前面的表的行组合，从该表中读取一行。这可能是最好的联接类型，除了const类型。它用在一个索引的所有部分被联接使用并且索引是UNIQUE或PRIMARY KEY"。eq_ref可以用于使用=比较带索引的列。
4、 ref 查询条件索引既不是UNIQUE也不是PRIMARY KEY的情况。ref可用于=或<或>操作符的带索引的列。
5、 ref_or_null 该联接类型如同ref，但是添加了MySQL可以专门搜索包含NULL值的行。在解决子查询中经常使用该联接类型的优化。
上面这五种情况都是很理想的索引使用情况。
6、 index_merge 该联接类型表示使用了索引合并优化方法。在这种情况下，key列包含了使用的索引的清单，key_len包含了使用的索引的最长的关键元素。
7、 unique_subquery 该类型替换了下面形式的IN子查询的ref: value IN (SELECT primary_key FROM single_table WHERE some_expr) unique_subquery是一个索引查找函数,可以完全替换子查询,效率更高。
8、 index_subquery 该联接类型类似于unique_subquery。可以替换IN子查询,但只适合下列形式的子查询中的非唯一索引: value IN (SELECT key_column FROM single_table WHERE some_expr)
9、 range 只检索给定范围的行,使用一个索引来选择行。
10、 index 该联接类型与ALL相同,除了只有索引树被扫描。这通常比ALL快,因为索引文件通常比数据文件小。
11、 ALL 对于每个来自于先前的表的行组合,进行完整的表扫描。（性能最差）
指出MySQL能使用哪个索引在该表中找到行。
如果该列为NULL，说明没有使用索引，可以对该列创建索引来提供性能。
显示MySQL实际决定使用的键(索引)。如果没有选择索引,键是NULL。
可以强制使用索引或者忽略索引：
显示MySQL决定使用的键长度。如果键是NULL,则长度为NULL。
注意：key_len是确定了MySQL将实际使用的索引长度。
显示使用哪个列或常数与key一起从表中选择行。
显示MySQL认为它执行查询时必须检查的行数。
该列包含MySQL解决查询的详细信息
· Distinct:MySQL发现第1个匹配行后,停止为当前的行组合搜索更多的行。
· Not exists:MySQL能够对查询进行LEFT JOIN优化,发现1个匹配LEFT JOIN标准的行后,不再为前面的的行组合在该表内检查更多的行。
· range checked for each record (index map: #):MySQL没有发现好的可以使用的索引,但发现如果来自前面的表的列值已知,可能部分索引可以使用。
· Using filesort:MySQL需要额外的一次传递,以找出如何按排序顺序检索行。
· Using index:从只使用索引树中的信息而不需要进一步搜索读取实际的行来检索表中的列信息。
· Using temporary:为了解决查询,MySQL需要创建一个临时表来容纳结果。
· Using where:WHERE 子句用于限制哪一个行匹配下一个表或发送到客户。
· Using sort_union(...), Using union(...), Using intersect(...):这些函数说明如何为index_merge联接类型合并索引扫描。
· Using index for group-by:类似于访问表的Using index方式,Using index for group-by表示MySQL发现了一个索引,可以用来查 询GROUP BY或DISTINCT查询的所有列,而不要额外搜索硬盘访问实际的表。
索引可以提供查询的速度，但并不是使用了带有索引的字段查询都会生效，有些情况下是不生效的，需要注意！
在使用LIKE关键字进行查询的查询语句中，如果匹配字符串的第一个字符为“%”，索引不起作用。只有“%”不在第一个位置，索引才会生效。
MySQL可以为多个字段创建索引，一个索引可以包括16个字段。对于联合索引，只有查询条件中使用了这些字段中第一个字段时，索引才会生效。
查询语句的查询条件中只有OR关键字，且OR前后的两个条件中的列都是索引时，索引才会生效，否则，索引不生效。
MySQL从4.1版本开始支持子查询，使用子查询进行SELECT语句嵌套查询，可以一次完成很多逻辑上需要多个步骤才能完成的SQL操作。
子查询虽然很灵活，但是执行效率并不高。
执行子查询时，MYSQL需要创建临时表，查询完毕后再删除这些临时表，所以，子查询的速度会受到一定的影响。
优化：
可以使用连接查询（JOIN）代替子查询，连接查询时不需要建立临时表，其速度比子查询快。
一个好的数据库设计方案对于数据库的性能往往会起到事半功倍的效果。
需要考虑数据冗余、查询和更新的速度、字段的数据类型是否合理等多方面的内容。
对于字段较多的表，如果有些字段的使用频率很低，可以将这些字段分离出来形成新表。
因为当一个表的数据量很大时，会由于使用频率低的字段的存在而变慢。
对于需要经常联合查询的表，可以建立中间表以提高查询效率。
通过建立中间表，将需要通过联合查询的数据插入到中间表中，然后将原来的联合查询改为对中间表的查询。
设计数据表时应尽量遵循范式理论的规约，尽可能的减少冗余字段，让数据库设计看起来精致、优雅。但是，合理的加入冗余字段可以提高查询速度。
表的规范化程度越高，表和表之间的关系越多，需要连接查询的情况也就越多，性能也就越差。
注意：
冗余字段的值在一个表中修改了，就要想办法在其他表中更新，否则就会导致数据不一致的问题。
插入数据时，影响插入速度的主要是索引、唯一性校验、一次插入的数据条数等。
插入数据的优化，不同的存储引擎优化手段不一样，在MySQL中常用的存储引擎有，MyISAM和InnoDB，两者的区别：
http://www.cnblogs.com/panfeng412/archive/2011/08/16/2140364.html
对于非空表，插入记录时，MySQL会根据表的索引对插入的记录建立索引。如果插入大量数据，建立索引会降低插入数据速度。
为了解决这个问题，可以在批量插入数据之前禁用索引，数据插入完成后再开启索引。
禁用索引的语句：
ALTER TABLE table_name DISABLE KEYS
开启索引语句：
ALTER TABLE table_name ENABLE KEYS
对于空表批量插入数据，则不需要进行操作，因为MyISAM引擎的表是在导入数据后才建立索引。
唯一性校验会降低插入记录的速度，可以在插入记录之前禁用唯一性检查，插入数据完成后再开启。
禁用唯一性检查的语句：SET UNIQUE_CHECKS = 0;
开启唯一性检查的语句：SET UNIQUE_CHECKS = 1;
插入数据时，可以使用一条INSERT语句插入一条数据，也可以插入多条数据。
第二种方式的插入速度比第一种方式快。
当需要批量导入数据时，使用LOAD DATA INFILE语句比INSERT语句插入速度快很多。
用法和MyISAM一样。
插入数据之前执行禁止对外键的检查，数据插入完成后再恢复，可以提供插入速度。
禁用：SET foreign_key_checks = 0;
开启：SET foreign_key_checks = 1;
插入数据之前执行禁止事务的自动提交，数据插入完成后再恢复，可以提供插入速度。
禁用：SET autocommit = 0;
开启：SET autocommit = 1;
服务器的硬件性能直接决定着MySQL数据库的性能，硬件的性能瓶颈，直接决定MySQL数据库的运行速度和效率。
需要从以下几个方面考虑：
1、 配置较大的内存。足够大的内存，是提高MySQL数据库性能的方法之一。内存的IO比硬盘快的多，可以增加系统的缓冲区容量，使数据在内存停留的时间更长，以减少磁盘的IO。
2、 配置高速磁盘，比如SSD。
3、 合理分配磁盘IO，把磁盘IO分散到多个设备上，以减少资源的竞争，提高并行操作能力。
4、 配置多核处理器，MySQL是多线程的数据库，多处理器可以提高同时执行多个线程的能力。
通过优化MySQL的参数可以提高资源利用率，从而达到提高MySQL服务器性能的目的。
MySQL的配置参数都在my.conf或者my.ini文件的[mysqld]组中，常用的参数如下：
要求：必须记忆至少3个。
