MyISAM

MyISAM，InnoDB主要区别： 　 　1.MyISAM是非事物安全的，InnoDB是事物安全的。 　　　　事物安全的特点为更安全，遇到问题会自动恢复或从备份加事物日志回复，如果更新失败，你的所有改变都变回原来。 　　　　非事物安全的优点为更快，所需的磁盘空间更小，执行更新时需要的内存更小，但是所有发生的改变都是永久的。 　　2.MyISAM锁的粒度是表级的，InnoDB支持行级锁以及表级，默认情况下是采用行级锁。 　　　　 数据库引擎具有多粒度锁定，允许一个事务锁定不同类型的资源。 为了尽量减少锁定的开销，数据库引擎自动将资源锁定在适合任务的级别。 锁定在较小的粒度（例如行）可以提高并发度，但开销较高，因为如果锁定了许多行，则需要持有更多的锁。 锁定在较大的粒度（例如表）会降低了并发度，因为锁定整个表限制了其他事务对表中任意部分的访问。 但其开销较低，因为需要维护的锁较少。 　 　3. MyISAM 支持全文类型索引，InnoDB不支持（ 之前 ） 。 　　　　mysql索引有四种类型：主键索引、唯一索引、普通索引和全文索引。通过给字段添加索引可以提高数据的读取速度，提高项目的并发能力和抗压能力。索引优化是mysql中的一种优化方式。索引的作用相当于图书的目录，可以根据目录中的页码快速找到所需的内容。 　　　　主键索引: 主键是一种唯一性索引，但它必须指定为PRIMARY

本文源码： GitHub·点这里 || GitEE·点这里 一、锁概念简介 1、基础描述 锁机制核心功能是用来协调多个会话中多线程并发访问相同资源时，资源的占用问题。锁机制是一个非常大的模块，贯彻MySQL的几大核心难点模块：索引，锁机制，事务。这里是基于MySQL5.6演示的几种典型场景，对面MySQL这几块问题时，有分析流程和思路是比较关键的。在MySQL中常见这些锁概念：共享读锁、排它写锁 ; 表锁、行锁、间隙锁。 2、存储引擎和锁 MyISAM引擎：基于读写两种模式，支持表级锁 ; InnoDB引擎：支持行级别读写锁，跨行的间隙锁,InnoDB也支持表锁 ; 3、锁操作API LOCK TABLE name [READ,WRITE] ;加表锁 UNLOCK TABLES ; 释放标所 二、MyISAM锁机制 1、基础描述 MySQL的表级锁有两种模式：共享读锁（Read-Lock）和排它写锁（Write-Lock）。针对MyISAM表的读操作，不会阻塞其他线程对同一表的读请求，但阻塞对同一表的写请求；针对MyISAM表的写操作，会阻塞其他线程对同一表的读和写操作；MyISAM引擎读写操作之间，以及写与写操作之间是串行化。当一次会话线程获取表的写锁后，只有当前持有锁的会话线程可以对表进行操作。其它线程的读、写操作都会等待，直到锁被释放为止。 2、验证案例

innodb_buffer_pool_size 如果用Innodb，那么这是一个重要变量。相对于MyISAM来说，Innodb对于buffer size更敏感。MySIAM可能对于大数据量使用默认的key_buffer_size也还好，但Innodb在大数据量时用默认值就感觉在爬了。 Innodb的缓冲池会缓存数据和索引，所以不需要给系统的缓存留空间，如果只用Innodb，可以把这个值设为内存的70%-80%。和 key_buffer相同，如果数据量比较小也不怎么增加，那么不要把这个值设太高也可以提高内存的使用率。 innodb_additional_pool_size 这个的效果不是很明显，至少是当操作系统能合理分配内存时。但你可能仍需要设成20M或更多一点以看Innodb会分配多少内存做其他用途。 innodb_log_file_size 对于写很多尤其是大数据量时非常重要。要注意，大的文件提供更高的性能，但数据库恢复时会用更多的时间。我一般用64M-512M，具体取决于服务器的空间。 innodb_log_buffer_size 默认值对于多数中等写操作和事务短的运用都是可以的。如 果经常做更新或者使用了很多blob数据，应该增大这个值。但太大了也是浪费内存，因为1秒钟总会 flush（这个词的中文怎么说呢？）一次，所以不需要设到超过1秒的需求。8M-16M一般应该够了

innodb_buffer_pool_size 如果用Innodb，那么这是一个重要变量。相对于MyISAM来说，Innodb对于buffer size更敏感。MySIAM可能对于大数据量使用默认的key_buffer_size也还好，但Innodb在大数据量时用默认值就感觉在爬了。 Innodb的缓冲池会缓存数据和索引，所以不需要给系统的缓存留空间，如果只用Innodb，可以把这个值设为内存的70%-80%。和 key_buffer相同，如果数据量比较小也不怎么增加，那么不要把这个值设太高也可以提高内存的使用率。 innodb_additional_pool_size 这个的效果不是很明显，至少是当操作系统能合理分配内存时。但你可能仍需要设成20M或更多一点以看Innodb会分配多少内存做其他用途。 innodb_log_file_size 对于写很多尤其是大数据量时非常重要。要注意，大的文件提供更高的性能，但数据库恢复时会用更多的时间。我一般用64M-512M，具体取决于服务器的空间。 innodb_log_buffer_size 默认值对于多数中等写操作和事务短的运用都是可以的。如果经常做更新或者使用了很多blob数据，应该增大这个值。但太大了也是浪费内存，因为1秒钟总会 flush（这个词的中文怎么说呢？）一次，所以不需要设到超过1秒的需求。8M-16M一般应该够了

某厂面试归来，发现自己落伍了！>>> 前言 当提到MySQL数据库的时候，我们的脑海里会想起几个关键字：索引、事务、数据库锁等等，索引是MySQL的灵魂，是平时进行查询时的利器，也是面试中的重中之重。 可能你了解索引的底层是b+树，会加快查询，也会在表中建立索引，但这是远远不够的，这里列举几个索引常见的面试题： 1、索引为什么要用b+树这种数据结构？ 2、聚集索引和非聚集索引的区别？ 3、索引什么时候会失效，最左匹配原则是什么？ 当遇到这些问题的时候，可能会发现自己对索引还是一知半解，今天我们一起学习MySQL的索引。 一、一条查询语句是如何执行的 首先来看在MySQL数据库中，一条查询语句是如何执行的，索引出现在哪个环节，起到了什么作用。 1.1 应用程序发现SQL到服务端 当执行SQL语句时，应用程序会连接到相应的数据库服务器，然后服务器对SQL进行处理。 1.2 查询缓存 接着数据库服务器会先去查询是否有该SQL语句的缓存，key是查询的语句，value是查询的结果。如果你的查询能够直接命中，就会直接从缓存中拿出value来返回客户端。 注：查询不会被解析、不会生成执行计划、不会被执行。 1.3 查询优化处理，生成执行计划 如果没有命中缓存，则开始第三步。 解析SQL：生成解析树，验证关键字如select,where,left join 等）是否正确。 预处理

1 ．获取当前配置参数 要优化配置参数，首先要了解当前的配置参数以及运行情况。使用下列命令可以获得目前服务器使用的配置参数： mysqld –verbose –help mysqladmin variables extended-status –u root –p 在 MySQL 控制台里面，运行下列命令可以获取状态变量的值： mysql> SHOW STATUS; 如果只要检查某几个状态变量，可以使用下列命令： mysql> SHOW STATUS LIKE ‘[ 匹配模式 ]’; ( 可以使用 % 、 ? 等 ) 2 ．优化参数 参数优化基于一个前提，就是在我们的数据库中通常都使用 InnoDB 表，而不使用 MyISAM 表。 在优化 MySQL 时，有两个配置参数是最重要的，即 table_cache 和 key_buffer_size 。 table_cache table_cache 指定表高速缓存的大小。 每当 MySQL 访问一个表时，如果在表缓冲区中还有空间，该表就被打开并放入其中，这样可以更快地访问表内容。通过检查峰值时间的状态值 Open_tables 和 Opened_tables ，可以决定是否需要增加 table_cache 的值。如果你发现 open_tables 等于 table_cache ，并且 opened_tables 在不断增长

目录 索引对比 锁对比 事务对比 并发 全文索引对比 外键 其他 一.索引对比 1.B+树概念 我们这里关注B+树的两个特性： 叶子节点包含数据data（data并不特指数据库中的某一行数据，也可以是某个数值，指针等） 叶子节点均在同一层，且每个节点均可以直接找到上一个或者下一个节点（双向指针，比常规的B+树多了一个指向上一个的指针） 2.Innodb 以用户表为例， id 为主键，另外name存在索引 idx_name ： CREATE TABLE `t_user` ( `id` bigint, `name` varchar(10), `age` int, PRIMARY KEY (`id`), KEY `idx_name` (`name`) ); 插入数据： insert into t_user (id,`name`,age) values (1,'n7',10), (2,'n6',20), (3,'n5',30), (4,'n4',40), (5,'n3',50), (6,'n2',60), (7,'n1',70) ①聚簇索引(聚集索引) 聚簇索引：行数据与键值（主键）紧凑地存储在一起； InnoDB中表现为：B+树叶子节点的data用于存放 行数据 （包含主键值、其他列数据、回滚指针、事务id等），物理上索引数据与行数据都放在同一个文件中（ .ibd ） 如果没有定义主键

某厂面试归来，发现自己落伍了！>>> 索引是帮助MySQL高效获取数据的排好序的数据结构 一.存储引擎 这里只讨论 使用最多的两种引擎【MyISAM】和【InnoDB】 1. MyISAM 引擎（非聚集） 上图是是使用myisam引擎的文件，可以看出：MyISAM索引文件和数据是分离的（非聚集）。 当一个查询带有索引，得先通过MYI文件（B+TREE）读取到该条数据的磁盘文件指针，因此再在MYD文件中获取到该条数据。如果查询条件不是索引，则直接去MYD文件去找，做全表扫描，效率低下。 2. InnoDB引擎（聚集） 表数据文件本身就是按B+Tree组织的一个索引结构文件如上图 此为 聚集索引 -叶节点包含了完整的数据记录 1、为什么InnoDB表必须有主键，并且推荐使用整型的自增主键?（ 整型比字符串大小判断效率更高，自增会不容易造成B+Tree分裂 ） 2、为什么非主键索引结构叶子节点存储的是主键值? ( 一致性和节省存储空间 ) 简单总结一下这两个引擎： InnoDB ：支持事务处理，支持外键，支持崩溃修复能力和并发控制。如果需要频繁的更新、删除操作的数据库，也可以选择InnoDB，因为支持事务的提交（commit）和回滚（rollback）。 MyISAM ：插入数据快，空间和内存使用比较低。如果表主要是用于插入新记录和读出记录，那么选择MyISAM能实现处理高效率

一、mysqlcheck 进行表的检查和修复 1、检查mysqlisam存储引擎表的状态 #mysqlcheck -uuser -ppassword database table -c #检查单个表是否损坏 #mysqlcheck -uuser -ppassword database -c #检查整个库那些表损坏 2、首先检查数据库的那些表损坏，如果能定位到那张表损坏可以直接对表修复 #mysqlcheck -uuser -ppassword database table -r # 修复数据表 #mysqlcheck -uuser -ppassword database -r # 修复整个数据库 二、myisamchk 修复mysql表 Myisamchk是MyISAM表维护的一个非常实用的工具。可以使用myisamchk实用程序来获得有关数据库表的信息或检查、修复、优化他们。myisamchk适用MyISAM表(对应.MYI和.MYD文件的表)。 Myisamchk 选项解释 –debug=debug_options, -# debug_options 输出调试记录文件。debug_options字符串经常是’d:t:o,filename’。 –silent，-s 沉默模式。仅当发生错误时写输出。 –wait, -w 如果表被锁定，不是提示错误终止，而是在继续前等待到表被解锁。

《 数据库索引，到底是什么做的？ 》介绍了B+树，它是一种非常适合用来做 数据库索引 的数据结构： (1)很适合磁盘存储，能够充分利用局部性原理，磁盘预读； (2)很低的树高度，能够存储大量数据； (3)索引本身占用的内存很小； (4)能够很好的支持单点查询，范围查询，有序性查询； 数据库的索引分为 主键索引 （Primary Inkex）与 普通索引 （Secondary Index）。InnoDB和MyISAM是怎么利用B+树来实现这两类索引，其又有什么差异呢？这是今天要聊的内容。 一，MyISAM的索引 MyISAM的 索引与行记录是分开存储的 ，叫做 非聚集索引 （UnClustered Index）。 其主键索引与普通索引没有本质差异： 有连续聚集的区域 单独存储行记录 主键索引的叶子节点，存储主键，与对应行记录的 指针 普通索引的叶子结点，存储索引列，与对应行记录的 指针 画外音：MyISAM的表可以没有主键。 主键索引与普通索引是两棵独立的索引B+树，通过索引列查找时，先定位到B+树的叶子节点，再通过指针定位到行记录。 举个例子，MyISAM： t(id PK, name KEY, sex, flag); 表中有四条记录： 1, shenjian, m, A 3, zhangsan, m, A 5, lisi, m, A 9, wangwu, f, B 其B