1.技术分享 | MySQL 字段长度限制的源码计算方法
2.为什么大家说mysql数据库单表最大两千万？依据是啥？
3.MySQL：排序（filesort）详细解析（8000字长文）
4.生产问题（三）Mysql for update 导致大量行锁
5.MySQL全文索引源码剖析之Insert语句执行过程
6.Mysql InnoDB和MyISAM的区别

技术分享 | MySQL 字段长度限制的计算方法

       本文由kay撰写，擅长Oracle、行数MySQL、源码PostgresSQL等领域，行数专注于Oracle和MySQL性能优化、源码数据库架构设计、行数bimserver源码故障修复、源码数据迁移和恢复，行数热衷于研究MySQL内核源码，源码并拥有Oracle OCP认证。行数目前在江苏国泰新点软件有限公司担任DBA技术团队成员。源码

       一、行数MySQL限制回顾

       之前在《MySQL Text字段的源码限制》一文中提及了MySQL在Server层和InnoDB层的限制，但未详细阐述限制计算方法。行数本文将对MySQL的源码两个限制进行补充说明：1. MySQL Server层限制单条记录大小不超过字节；2. InnoDB层限制不能超过innodb_page_size的一半，以默认K设置为例，限制为。下文内容基于MySQL 5.7.进行说明。

       二、Server层限制的计算方法

       2.1 计算过程

       若MySQL Server层面限制，则会返回特定报错信息。关键代码路径在于`pack_header`中，具体在于判断`reclength`值是否大于。因此，了解`reclength`的计算过程至关重要。

       2.2 小结

       根据上述计算方式，MySQL Server层计算长度的公式为：`total_length <= `。满足此条件即可通过MySQL Server层的检查。

       三、InnoDB层限制的计算方法

       3.1 计算过程

       InnoDB层面限制的报错信息中，关键代码路径在于判断`page_rec_max`值。根据源码定义，`srv_page_size`默认值为1<<即，配置也是。而`UNIV_PAGE_SIZE_MAX`值为1<<即。因此，`srv_page_size`不等于`UNIV_PAGE_SIZE_MAX`。计算`page_rec_max`值为`page_get_free_space_of_empty(comp) / 2`。安卓源码架设进一步分析，一条记录实际长度（`rec_max_size`）的计算公式如下。

       3.2 小结

       在InnoDB层计算长度的公式为：`rec_max_size < `。满足此条件即可通过InnoDB层的检查。

       四、总结

       1. 必须同时满足MySQL Server层和InnoDB层的限制条件，才能成功创建表。

       2. 遇到上述报错情况时，多数原因在于varchar等字段设置过大。建议对字段逐步缩小或使用text替代。

为什么大家说mysql数据库单表最大两千万？依据是啥？

       故事从好多年前说起。想必大家也听说过数据库单表建议最大2kw条数据这个说法。如果超过了，性能就会下降得比较厉害。我当初设计时哪里想到这表竟然能涨这么快。。。

       数据库单表行数理论最大值是多少？建表的SQL是这么写的，其中id就是主键。主键本身唯一，也就是说主键的大小可以限制表的上限。如果主键声明为int大小，也就是位，那么能支持2^-1，也就是个亿左右。如果是bigint，那就是2^-1，但这个数字太大，一般还没到这个限制之前，磁盘先受不了。

       除了主键，还有哪些因素会影响行数？索引的结构内部是用的B+树，这个也是八股文老股了，大家估计也背得很熟了。为了不让大家有过于强烈的审丑疲劳，今天我尝试从另外一个角度给大家讲讲这玩意。假设我们有这么一张user数据表。安卓分销源码user表其中id是唯一主键。这看起来的一行行数据，为了方便，我们后面就叫它们record吧。这张表看起来就跟个excel表格一样。excel的数据在硬盘上是一个xx.excel的文件。而上面user表数据，在硬盘上其实也是类似，放在了user.ibd文件下。含义是user表的innodb data文件，专业点，又叫表空间。虽然在数据表里，它们看起来是挨在一起的。但实际上在user.ibd里他们被分成很多小份的数据页，每份大小k。

       整个页k，不大，但record这么多，一页肯定放不下，所以会分开放到很多页里。并且这k，也不可能全用来放record对吧。因为record们被分成好多份，放到好多页里了，为了唯一标识具体是哪一页，那就需要引入页号（其实是一个表空间的地址偏移量）。同时为了把这些数据页给关联起来，于是引入了前后指针，用于指向前后的页。这些都被加到了页头里。页是需要读写的，k说小也不小，写一半电源线被拔了也是有可能发生的，所以为了保证数据页的正确性，还引入了校验码。这个被加到了页尾。3.4大富豪 源码那剩下的空间，才是用来放我们的record的。而record如果行数特别多的话，进入到页内时挨个遍历，效率也不太行，所以为这些数据生成了一个页目录，具体实现细节不重要。只需要知道，它可以通过二分查找的方式将查找效率从O(n) 变成O(lgn)。

       页结构从页到索引如果想查一条record，我们可以把表空间里每一页都捞出来，再把里面的record捞出来挨个判断是不是我们要找的。行数量小的时候，这么操作也没啥问题。行数量大了，性能就慢了，于是为了加速搜索，我们可以在每个数据页里选出主键id最小的record，而且只需要它们的主键id和所在页的页号。组成新的record，放入到一个新生成的一个数据页中，这个新数据页跟之前的页结构没啥区别，而且大小还是k。但为了跟之前的数据页进行区分。数据页里加入了页层级（page level）的信息，从0开始往上算。于是页与页之间就有了上下层级的概念，就像下面这样。两层B+树结构突然页跟页之间看起来就像是一棵倒过来的树了。也就是我们常说的B+树索引。最下面那一层，page level 为0，也就是所谓的叶子结点，其余都叫非叶子结点。上面展示的是两层的树，如果数据变多了，我们还可以再通过类似的云支付平台源码方法，再往上构建一层。就成了三层的树。三层B+树结构那现在我们就可以通过这样一棵B+树加速查询。举个例子。比方说我们想要查找行数据5。会先从顶层页的record们入手。record里包含了主键id和页号（页地址）。看下图**的箭头，向左最小id是1，向右最小id是7。那id=5的数据如果存在，那必定在左边箭头。于是顺着的record的页地址就到了6号数据页里，再判断id=5>4，所以肯定在右边的数据页里，于是加载号数据页。在数据页里找到id=5的数据行，完成查询。B+树查询过程另外需要注意的是，上面的页的页号并不是连续的，它们在磁盘里也不一定是挨在一起的。这个过程中查询了三个页，如果这三个页都在磁盘中（没有被提前加载到内存中），那么最多需要经历三次磁盘IO查询，它们才能被加载到内存中。

       B+树承载的记录数量从上面的结构里可以看出B+树的最末级叶子结点里放了record数据。而非叶子结点里则放了用来加速查询的索引数据。也就是说同样一个k的页，非叶子节点里每一条数据都指向一个新的页，而新的页有两种可能。假设总行数的计算方法那这棵B+树放的行数据总量等于 (x ^ (z-1)) * y。x怎么算我们回去看数据页的结构。页结构非叶子节点里主要放索引查询相关的数据，放的是主键和指向页号。主键假设是bigint（8Byte），而页号在源码里叫FIL_PAGE_OFFSET（4Byte），那么非叶子节点里的一条数据是Byte左右。整个数据页k，页头页尾那部分数据全加起来大概Byte，加上页目录毛估占1k吧。那剩下的k除以Byte，等于，也就是可以指向x=页。我们常说的二叉树指的是一个结点可以发散出两个新的结点。m叉树一个节点能指向m个新的结点。这个指向新节点的操作就叫扇出（fanout）。而上面的B+树，它能指向个新的节点，恐怖如斯，可以说扇出非常高了。y的计算叶子节点和非叶子节点的数据结构是一样的，所以也假设剩下kb可以发挥。叶子节点里放的是真正的行数据。假设一条行数据1kb，所以一页里能放y=行。行总数计算回到(x ^ (z-1)) * y 这个公式。已知x=，y=。假设B+树是两层，那z=2。则是( ^ (2-1)) * ≈ 2w 假设B+树是三层，那z=3。则是( ^ (3-1)) * ≈ 2.5kw 这个2.5kw，就是我们常说的单表建议最大行数2kw的由来。毕竟再加一层，数据就大得有点离谱了。三层数据页对应最多三次磁盘IO，也比较合理。

MySQL：排序（filesort）详细解析（字长文）

       MySQL排序详解：深入理解filesort过程（简化版）

       MySQL中的排序（filesort）是DBA工作中常见的操作，本文主要针对Innodb引擎，使用5.7.源码版本，针对快速排序和归并排序进行详细解析。filesort在执行计划中表示排序操作，但执行计划本身并不揭示所有细节。

       首先，我们从一个问题出发，介绍一个朋友遇到的案例，排序后临时文件意外达G。我们将通过实例逐步分析排序的流程。

       1. 确认排序字段：从order by语句开始，如"a2,a3"，并存储在Filesort的sortorder中，涉及原始和修改的filesort算法，但本文不涉及复杂算法分支。

       2. 计算sort字段长度：通过sortlength函数，考虑每个字段的长度，如varchar()，长度计算为字符数量的两倍。超过max_sort_length设置的字段将导致排序精度下降。

       3. 确定addon字段空间：根据max_length_for_sort_data，判断是否使用回表排序算法。如a1、a2、a3都是需要的字段，且总长度超过字节，会使用回表排序。

       4. 计算每行数据长度：考虑sort字段和addon字段，包括可能的打包压缩。在内存排序阶段，将数据按照计算出的长度存储。

       5. 分配内存：根据sort_buffer_size和表大小，计算实际需要的内存，并进行内存排序。

       6. 内存排序与外部归并：如果数据量大，内存排序后会写入临时文件，进行外部归并排序。

       7. 排序方式总结：文件sort函数会输出排序方式，如sort_key+packed_additional_fields（不回表排序，打包字段）或sort_key+additional_fields（固定长度字段）。

       8. 最终排序：可能生成额外的临时文件，存储归并排序结果，文件数量根据排序量变化。

       9. 问题：original filesort算法的回表和Rows_examined的计算。

       . 使用OPTIMIZER_TRACE查看排序结果，理解排序过程和使用的内存。

       案例中，通过group by操作的排序，如果sort字段过大，会使用回表排序，导致临时文件占用巨大。总结排序过程包括了组织排序数据的方式、排序方法的选择、内存分配策略以及临时文件的管理。

       理解排序过程对优化查询性能和避免大文件临时文件至关重要。通过合理设计和使用索引，以及优化排序策略，可以有效控制临时文件的大小。

生产问题（三）Mysql for update 导致大量行锁

       在一次复盘会上，我的同事分享了一次因误用了 Mysql 的 for update 命令，导致大量行锁产生的问题。这一情况引起了我的深思，因为在网上广泛流传的观点认为 InnoDB 存在锁升级，表锁的产生与数据量、锁的类型有关。然而，这一观点基于对《高性能 Mysql》和《Innodb 存储引擎》的深入理解，实则存在误解。

       在环境设定为 Mysql5.7，隔离级别为 RC 的情况下，我发现 for update 一个不存在的 where 条件时，InnoDB 加的是 Record 级别的锁。这一点通过执行查询信息得到验证，信息显示两个事务加的都是行级别锁。

       对于锁住的行数量与数据的准确性，我注意到在相关书籍中提到的锁数据统计方式可能不够精确。而当 for update 命令无法根据索引加锁时，InnoDB 实际上会在行数据中进行搜索，并对主键进行加锁，而不是整个表。这种设计的初衷可能是为了提升效率，但具体设计考虑则无从得知。

       在 InnoDB 加锁机制中，锁的获取遵循从上至下的逻辑，即自动加锁只包括表级别的意向锁和行级锁。表级别的意向锁仅阻塞全表扫描，不会影响其他操作。在 RR 隔离级别下，InnoDB 会采取 GapLock 和 Next-keyLock 算法，以防止插入数据导致的幻读问题，但这一操作并非绝对，对于唯一索引而言，InnoDB 可能会降低级别使用行级锁，避免锁住范围。

       总结来看，基于对实际操作的验证和对权威书籍的理解，可以得出以下

在 RC 级别下，InnoDB 的加锁机制主要为行级锁，表级的意向锁仅阻塞全表扫描。InnoDB 并不存在锁升级的现象。当 for update 命令未能通过索引加锁时，InnoDB 会在行数据中对主键进行加锁。

       通过这一分析，我与 DBA 进行了深入讨论，对这些观点进行了确认。对于这一问题，我鼓励大家在实际操作、阅读权威书籍和源码时，保持批判性思考，避免盲从网上信息。书籍与源码的阅读应结合实际经验，因为个人理解能力的差异可能导致理解方向的偏差。

       原创声明：

       本文章由我独立创作，内容均为原创。

       如有需要转载或使用本文章内容，请注明出处。

MySQL全文索引源码剖析之Insert语句执行过程

       本文来源于华为云社区，作者为GaussDB数据库，探讨了MySQL全文索引源码中Insert语句的执行过程。

       全文索引是一种常用于信息检索的技术，它通过倒排索引实现，即单词和文档的映射关系，如(单词，(文档，偏移))。以创建一个表并在opening_line列上建立全文索引为例，插入'Call me Ishmael.'时，文档会被分为'call', 'me', 'ishmael'等单词，并记录在全文索引中。

       全文索引Cache的作用类似于Change Buffer，用于缓存分词结果，避免频繁刷盘。Innodb使用fts_cache_t结构来管理cache，每个全文索引的表都会在内存中创建一个fts_cache_t对象。

       Insert语句的执行分为三个阶段：写入行记录阶段、事务提交阶段和刷脏阶段。写入行记录阶段生成doc_id并写入Innodb的行记录，并将doc_id缓存。事务提交阶段对文档进行分词，获取{ 单词，(文档，偏移)}关联对，并插入到cache。刷脏阶段后台线程将cache刷新到磁盘。

       全文索引的并发插入可能导致OOM问题，可通过修复patch #解决。当MySQL进程崩溃时，fts_init_index函数会恢复crash前的cache数据。

Mysql InnoDB和MyISAM的区别

       ã€€ã€€InnoDB和MyISAM是在使用MySQL最常用的两个表类型，各有优缺点，视具体应用而定。基本的差别为：MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持已经外部键等高级数据库功能。

       ã€€ã€€MyIASM是IASM表的新版本，有如下扩展：

       ã€€ã€€äºŒè¿›åˆ¶å±‚次的可移植性。

       ã€€ã€€NULL列索引。

       ã€€ã€€å¯¹å˜é•¿è¡Œæ¯”ISAM表有更少的碎片。

       ã€€ã€€æ”¯æŒå¤§æ–‡ä»¶ã€‚

       ã€€ã€€æ›´å¥½çš„索引压缩。

       ã€€ã€€æ›´å¥½çš„键吗统计分布。

       ã€€ã€€æ›´å¥½å’Œæ›´å¿«çš„auto_increment处理。

       ã€€ã€€ä»¥ä¸‹æ˜¯ä¸€äº›ç»†èŠ‚和具体实现的差别：

       ã€€ã€€1.InnoDB不支持FULLTEXT类型的索引。

       ã€€ã€€2.InnoDB中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count(*)语句包含where条件时，两种表的操作是一样的。

       ã€€ã€€3.对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。

       ã€€ã€€4.DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。

       ã€€ã€€5.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性（例如外键）的表不适用。

       ã€€ã€€å¦å¤–，InnoDB表的行锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%”

       ã€€ã€€ä»»ä½•ä¸€ç§è¡¨éƒ½ä¸æ˜¯ä¸‡èƒ½çš„，只用恰当的针对业务类型来选择合适的表类型，才能最大的发挥MySQL的性能优势.

       ã€€ã€€

       ã€€ã€€MySQL中MyISAM引擎与InnoDB引擎性能简单测试

       ã€€ã€€[硬件配置]

       ã€€ã€€CPU : AMD+ (1.8G)

       ã€€ã€€å†…å­˜: 1G/现代

       ã€€ã€€ç¡¬ç›˜: G/IDE

       ã€€ã€€[软件配置]

       ã€€ã€€OS : Windows XP SP2

       ã€€ã€€SE : PHP5.2.1

       ã€€ã€€DB : MySQL5.0.

       ã€€ã€€Web: IIS6

       ã€€ã€€[MySQL表结构]

       ã€€ã€€CREATE TABLE `myisam` (

       ã€€ã€€`id` int() NOT NULL auto_increment,

       ã€€ã€€`name` varchar() default NULL,

       ã€€ã€€`content` text,

       ã€€ã€€PRIMARY KEY (`id`)

       ã€€ã€€) ENGINE=MyISAM DEFAULT CHARSET=gbk;

       ã€€ã€€CREATE TABLE `innodb` (

       ã€€ã€€`id` int() NOT NULL auto_increment,

       ã€€ã€€`name` varchar() default NULL,

       ã€€ã€€`content` text,

       ã€€ã€€PRIMARY KEY (`id`)

       ã€€ã€€) ENGINE=InnoDB DEFAULT CHARSET=gbk;

       ã€€ã€€[数据内容]

       ã€€ã€€$name = "heiyeluren";

       ã€€ã€€$content = "MySQL支持数个存储引擎作为对不同表的类型的处理器。MySQL存储引擎包括处理事务安全表的引擎和处理非事务安全表的引擎：· MyISAM管理非事务表。它提供高速存储和检索，以及全文搜索能力。MyISAM在所有MySQL配置里被支持，它是默认的存储引擎，除非你配置MySQL默认使用另外一个引擎。 ·MEMORY存储引擎提供“内存中”表。MERGE存储引擎允许集合将被处理同样的MyISAM表作为一个单独的表。就像MyISAM一样，MEMORY和MERGE存储引擎处理非事务表，这两个引擎也都被默认包含在MySQL中。 释：MEMORY存储引擎正式地被确定为HEAP引擎。· InnoDB和BDB存储引擎提供事务安全表。BDB被包含在为支持它的操作系统发布的MySQL-Max二进制分发版里。InnoDB也默认被包括在所有MySQL 5.1二进制分发版里，你可以按照喜好通过配置MySQL来允许或禁止任一引擎。·EXAMPLE存储引擎是一个“存根”引擎，它不做什么。你可以用这个引擎创建表，但没有数据被存储于其中或从其中检索。这个引擎的目的是服务，在MySQL源代码中的一个例子，它演示说明如何开始编写新存储引擎。同样，它的主要兴趣是对开发者。";

       ã€€ã€€[插入数据-1] (innodb_flush_log_at_trx_commit=1)

       ã€€ã€€MyISAM 1W：3/s

       ã€€ã€€InnoDB 1W：/s

       ã€€ã€€MyISAM W：/s

       ã€€ã€€InnoDB W：/s

       ã€€ã€€MyISAM W：/s

       ã€€ã€€InnoDB W：没敢测试

       ã€€ã€€[插入数据-2] (innodb_flush_log_at_trx_commit=0)

       ã€€ã€€MyISAM 1W：3/s

       ã€€ã€€InnoDB 1W：3/s

       ã€€ã€€MyISAM W：/s

       ã€€ã€€InnoDB W：/s

       ã€€ã€€MyISAM W：/s

       ã€€ã€€InnoDB W：/s

       ã€€ã€€[插入数据3] (innodb_buffer_pool_size=M)

       ã€€ã€€InnoDB 1W：3/s

       ã€€ã€€InnoDB W：/s

       ã€€ã€€InnoDB W：/s

       ã€€ã€€[插入数据4] (innodb_buffer_pool_size=M, innodb_flush_log_at_trx_commit=1, set autocommit=0)

       ã€€ã€€InnoDB 1W：3/s

       ã€€ã€€InnoDB W：/s

       ã€€ã€€InnoDB W：/s

       ã€€ã€€[MySQL 配置文件] (缺省配置)

       ã€€ã€€# MySQL Server Instance Configuration File

       ã€€ã€€[client]

       ã€€ã€€port=

       ã€€ã€€[mysql]

       ã€€ã€€default-character-set=gbk

       ã€€ã€€[mysqld]

       ã€€ã€€port=

       ã€€ã€€basedir="C:/mysql/"

       ã€€ã€€datadir="C:/mysql/Data/"

       ã€€ã€€default-character-set=gbk

       ã€€ã€€default-storage-engine=INNODB

       ã€€ã€€sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

       ã€€ã€€max_connections=

       ã€€ã€€query_cache_size=0

       ã€€ã€€table_cache=

       ã€€ã€€tmp_table_size=M

       ã€€ã€€thread_cache_size=8

       ã€€ã€€myisam_max_sort_file_size=G

       ã€€ã€€myisam_max_extra_sort_file_size=G

       ã€€ã€€myisam_sort_buffer_size=M

       ã€€ã€€key_buffer_size=M

       ã€€ã€€read_buffer_size=K

       ã€€ã€€read_rnd_buffer_size=K

       ã€€ã€€sort_buffer_size=K

       ã€€ã€€innodb_additional_mem_pool_size=4M

       ã€€ã€€innodb_flush_log_at_trx_commit=1

       ã€€ã€€innodb_log_buffer_size=2M

       ã€€ã€€innodb_buffer_pool_size=M

       ã€€ã€€innodb_log_file_size=M

       ã€€ã€€innodb_thread_concurrency=8

       ã€€ã€€ã€æ€»ç»“】

       ã€€ã€€å¯ä»¥çœ‹å‡ºåœ¨MySQL 5.0里面，MyISAM和InnoDB存储引擎性能差别并不是很大，针对InnoDB来说，影响性能的主要是 innodb_flush_log_at_trx_commit 这个选项，如果设置为1的话，那么每次插入数据的时候都会自动提交，导致性能急剧下降，应该是跟刷新日志有关系，设置为0效率能够看到明显提升，当然，同样你可以SQL中提交“SET AUTOCOMMIT = 0”来设置达到好的性能。另外，还听说通过设置innodb_buffer_pool_size能够提升InnoDB的性能，但是我测试发现没有特别明显的提升。

       ã€€ã€€åŸºæœ¬ä¸Šæˆ‘们可以考虑使用InnoDB来替代我们的MyISAM引擎了，因为InnoDB自身很多良好的特点，比如事务支持、存储过程、视图、行级锁定等等，在并发很多的情况下，相信InnoDB的表现肯定要比MyISAM强很多，当然，相应的在my.cnf中的配置也是比较关键的，良好的配置，能够有效的加速你的应用。

       ã€€ã€€å¦‚果不是很复杂的Web应用，非关键应用，还是可以继续考虑MyISAM的，这个具体情况可以自己斟酌。

innodb和myisam的区别

       InnoDBMyISAM使用MySQL用两表类型各优缺点视具体应用定基本差别：MyISAM类型支持事务处理等高级处理InnoDB类型支持MyISAM类型表强调性能其执行数度比InnoDB类型更快提供事务支持InnoDB提供事务支持已经外部键等高级数据库功能　　MyIASMIASM表新版本扩展：　　二进制层移植性　　NULL列索引　　变行比ISAM表更少碎片　　支持文件　　更索引压缩　　更键统计布　　更更快auto_increment处理　　些细节具体实现差别：　　1.InnoDB支持FULLTEXT类型索引　　2.InnoDB保存表具体行数说执行select count(*) from tableInnoDB要扫描遍整表计算少行MyISAM要简单读保存行数即注意count(*)语句包含where条件两种表操作　　3.于AUTO_INCREMENT类型字段InnoDB必须包含该字段索引MyISAM表其字段起建立联合索引　　4.DELETE FROM tableInnoDB重新建立表行行删除　　5.LOAD TABLE FROM MASTER操作InnoDB起作用解决首先InnoDB表改MyISAM表导入数据再改InnoDB表于使用额外InnoDB特性（例外键）表适用　　另外InnoDB表行锁绝执行SQL语句MySQL能确定要扫描范围InnoDB表同锁全表例update table set num=1 where name like %aaa%　　任何种表都万能用恰针业务类型选择合适表类型才能发挥MySQL性能优势.　　　　MySQLMyISAM引擎与InnoDB引擎性能简单测试　　[硬件配置]　　CPU : AMD+ (1.8G)　　内存: 1G/现代　　硬盘: G/IDE　　[软件配置]　　OS : Windows XP SP2　　SE : PHP5.2.1　　DB : MySQL5.0.　　Web: IIS6　　[MySQL表结构]　　CREATE TABLE `myisam` (　　`id` int() NOT NULL auto_increment,　　`name` varchar() default NULL,　　`content` text,　　PRIMARY KEY (`id`)　　) ENGINE=MyISAM DEFAULT CHARSET=gbk;　　CREATE TABLE `innodb` (　　`id` int() NOT NULL auto_increment,　　`name` varchar() default NULL,　　`content` text,　　PRIMARY KEY (`id`)　　) ENGINE=InnoDB DEFAULT CHARSET=gbk;　　[数据内容]　　$name = "heiyeluren";　　$content = "MySQL支持数存储引擎作同表类型处理器MySQL存储引擎包括处理事务安全表引擎处理非事务安全表引擎：· MyISAM管理非事务表提供高速存储检索及全文搜索能力MyISAM所MySQL配置支持默认存储引擎除非配置MySQL默认使用另外引擎 ·MEMORY存储引擎提供内存表MERGE存储引擎允许集合处理同MyISAM表作单独表像MyISAMMEMORYMERGE存储引擎处理非事务表两引擎都默认包含MySQL 释：MEMORY存储引擎式确定HEAP引擎· InnoDBBDB存储引擎提供事务安全表BDB包含支持操作系统发布MySQL-Max二进制发版InnoDB默认包括所MySQL 5.1二进制发版按照喜通配置MySQL允许或禁止任引擎·EXAMPLE存储引擎存根引擎做用引擎创建表没数据存储于其或其检索引擎目服务MySQL源代码例演示说明何始编写新存储引擎同主要兴趣发者";　　[插入数据-1] (innodb_flush_log_at_trx_commit=1)　　MyISAM 1W：3/s　　InnoDB 1W：/s　　MyISAM W：/s　　InnoDB W：/s　　MyISAM W：/s　　InnoDB W：没敢测试　　[插入数据-2] (innodb_flush_log_at_trx_commit=0)　　MyISAM 1W：3/s　　InnoDB 1W：3/s　　MyISAM W：/s　　InnoDB W：/s　　MyISAM W：/s　　InnoDB W：/s　　[插入数据3] (innodb_buffer_pool_size=M)　　InnoDB 1W：3/s　　InnoDB W：/s　　InnoDB W：/s　　[插入数据4] (innodb_buffer_pool_size=M, innodb_flush_log_at_trx_commit=1, set autocommit=0)　　InnoDB 1W：3/s　　InnoDB W：/s　　InnoDB W：/s　　[MySQL 配置文件] (缺省配置)　　# MySQL Server Instance Configuration File　　[client]　　port=　　[mysql]　　default-character-set=gbk　　[mysqld]　　port=　　basedir="C:/mysql/"　　datadir="C:/mysql/Data/"　　default-character-set=gbk　　default-storage-engine=INNODB　　sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"　　max_connections=　　query_cache_size=0　　table_cache=　　tmp_table_size=M　　thread_cache_size=8　　myisam_max_sort_file_size=G　　myisam_max_extra_sort_file_size=G　　myisam_sort_buffer_size=M　　key_buffer_size=M　　read_buffer_size=K　　read_rnd_buffer_size=K　　sort_buffer_size=K　　innodb_additional_mem_pool_size=4M　　innodb_flush_log_at_trx_commit=1　　innodb_log_buffer_size=2M　　innodb_buffer_pool_size=M　　innodb_log_file_size=M　　innodb_thread_concurrency=8　　【总结】　　看MySQL 5.0面MyISAMInnoDB存储引擎性能差别并针InnoDB说影响性能主要 innodb_flush_log_at_trx_commit 选项设置1每插入数据候都自提交导致性能急剧降应该跟刷新志关系设置0效率能够看明显提升同SQL提交SET AUTOCOMMIT = 0设置达性能另外听说通设置innodb_buffer_pool_size能够提升InnoDB性能我测试发现没特别明显提升　　基本我考虑使用InnoDB替代我MyISAM引擎InnoDB自身良特点比事务支持、存储程、视图、行级锁定等等并发情况相信InnoDB表现肯定要比MyISAM强相应my.cnf配置比较关键良配置能够效加速应用　　复杂Web应用非关键应用继续考虑MyISAM具体情况自斟酌Mysql InnoDBMyISAM区别