大佬们求帮助，怎么让wincc查询sql客户资料数据库库客户资料数据库啊

进了互联网公司整天也就是搬磚，等到了面试的时候发现客户资料数据库库方面，忘得一塌糊涂抽时间整理了一些客户资料数据库库方面的题。欢迎大家向我推荐伱在面试过程中遇到的问题,我会把大家推荐的问题添加到下面的常用面试题清单中供大家参考

望各路大牛，发现不对的地方不吝赐教，留言即可

• 事务四大特性（ACID）原子性、一致性、隔离性、持久性？
• 事务的并发事务隔离级别，每个级别会引发什么问题MySQL默认是哪个級别？
• MySQL的MyISAM与InnoDB两种存储引擎在事务、锁级别，各自的适用场景
• 什么是临时表，临时表什么时候删除?
• 聚集索引和非聚集索引区别
• 有哪些鎖（乐观锁悲观锁），select 时怎么加排它锁
• 非关系型客户资料数据库库和关系型客户资料数据库库区别，优势比较
• 客户资料数据库库三范式，根据某个场景设计客户资料数据库表
• 客户资料数据库库的读写分离、主从复制，主从复制分析的 7 个问题
• MySQL慢查询怎么解决？
• 什么是 內连接、外连接、交叉连接、笛卡尔积等
• mysql都有什么锁，死锁判定原理和具体场景死锁怎么解决？
• mysql 高并发环境解决方案
• 客户资料数据庫库崩溃时事务的恢复机制（REDO日志和UNDO日志）？

【福利】关注微信公众号 "搜云库" 获取最新文章

【福利】公众号后台回复 “进群” 拉你进微信【技术分享群】

【福利】在里面你可以认识到很多搞技术大佬免费提问，互相学习

• 原子性是指事务包含的所有操作要么全部成功要么铨部失败回滚，因此事务的操作如果成功就必须要完全应用到客户资料数据库库如果操作失败则不能对客户资料数据库库有任何影响。

• 倳务开始前和结束后客户资料数据库库的完整性约束没有被破坏。比如A向B转账不可能A扣了钱，B却没收到

• 隔离性是当多个用户并发访問客户资料数据库库时，比如操作同一张表时客户资料数据库库为每一个用户开启的事务，不能被其他事务的操作所干扰多个并发事務之间要相互隔离。

同一时间只允许一个事务请求同一客户资料数据库，不同的事务之间彼此没有任何干扰比如A正在从一张银行卡中取钱，在A取钱的过程结束前B不能向这张卡转账。

关于事务的隔离性客户资料数据库库提供了多种隔离级别稍后会介绍到。 　 持久性（Durability）

• 持久性是指一个事务一旦被提交了那么对客户资料数据库库中的客户资料数据库的改变就是永久性的，即便是在客户资料数据库库系統遇到故障的情况下也不会丢失提交事务的操作

从理论上来说, 事务应该彼此完全隔离, 以避免并发事务所导致的问题，然而, 那样会对性能產生极大的影响, 因为事务必须按顺序运行 在实际开发中, 为了提升性能, 事务会以较低的隔离级别运行， 事务的隔离级别可以通过隔离事务屬性指定

1、脏读：事务A读取了事务B更新的客户资料数据库，然后B回滚操作那么A读取到的客户资料数据库是脏客户资料数据库

2、不可重複读：事务 A 多次读取同一客户资料数据库，事务 B 在事务A多次读取的过程中对客户资料数据库作了更新并提交，导致事务A多次读取同一客戶资料数据库时结果因此本事务先后两次读到的客户资料数据库结果会不一致。

3、幻读：幻读解决了不重复读保证了同一个事务里，查询的结果都是事务开始时的状态（一致性）

例如：事务T1对一个表中所有的行的某个客户资料数据库项做了从“1”修改为“2”的操作 这時事务T2又对这个表中插入了一行客户资料数据库项，而这个客户资料数据库项的数值还是为“1”并且提交给客户资料数据库库 而操作事務T1的用户如果再查看刚刚修改的客户资料数据库，会发现还有跟没有修改一样其实这行是从事务T2中添加的，就好像产生幻觉一样这就昰发生了幻读。

小结：不可重复读的和幻读很容易混淆不可重复读侧重于修改，幻读侧重于新增或删除解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表 　　

• 读未提交：另一个事务修改了客户资料数据库，但尚未提交而本事务中的SELECT会读到这些未被提茭的客户资料数据库脏读
• 不可重复读：事务 A 多次读取同一客户资料数据库，事务 B 在事务A多次读取的过程中对客户资料数据库作了更新并提交，导致事务A多次读取同一客户资料数据库时结果因此本事务先后两次读到的客户资料数据库结果会不一致。
• 可重复读：在同一个事務里SELECT的结果是事务开始时时间点的状态，因此同样的SELECT操作读到的结果会是一致的。但是会有幻读现象
• 串行化：最高的隔离级别，在這个隔离级别下不会产生任何异常。并发的事务就像事务是在一个个按照顺序执行一样

• 事务的隔离级别要得到底层客户资料数据库库引擎的支持, 而不是应用程序或者框架的支持.

1. SQL规范所规定的标准，不同的客户资料数据库库具体的实现可能会有些差异
2. MySQL中默认事务隔离级别昰“可重复读”时并不会锁住读取到的行

• 事务隔离级别：未提交读时写客户资料数据库只会锁住相应的行。
• 事务隔离级别为：可重复读時写客户资料数据库会锁住整张表。
• 事务隔离级别为：串行化时读写客户资料数据库都会锁住整张表。

隔离级别越高越能保证客户資料数据库的完整性和一致性，但是对并发性能的影响也越大鱼和熊掌不可兼得啊。对于多数应用程序可以优先考虑把客户资料数据庫库系统的隔离级别设为Read Committed，它能够避免脏读取而且具有较好的并发性能。尽管它会导致不可重复读、幻读这些并发问题在可能出现这類问题的个别场合，可以由应用程序采用悲观锁或乐观锁来控制

虽然MySQL里的存储引擎不只是MyISAM与InnoDB这两个，但常用的就是两个

两种存储引擎嘚大致区别表现在：

• InnoDB支持事务，MyISAM不支持这一点是非常之重要。事务是一种高级的处理方式如在一些列增删改中只要哪个出错还可以回滾还原，而MyISAM就不可以了
• MyISAM适合查询以及插入为主的应用。
• InnoDB适合频繁修改以及涉及到安全性较高的应用
• InnoDB中不保存表的行数，如select count(*) from table时InnoDB需要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可注意的是，当count(*)语句包含where条件时MyISAM也需要扫描整个表
• 对于自增长的芓段，InnoDB中必须包含只有该字段的索引但是在MyISAM表中可以和其他字段一起建立联合索引。
• DELETE FROM table时InnoDB不会重新建立表，而是一行一行的 删除效率非常慢。MyISAM则会重建表

关于MySQL客户资料数据库库提供的两种存储引擎，MyISAM与InnoDB选择使用：

• INNODB会支持一些关系客户资料数据库库的高级功能如事务功能和行级锁，MyISAM不支持
• MyISAM的性能更优，占用的存储空间少所以，选择何种存储引擎视具体应用而定。
• 如果你的应用程序一定要使用事務毫无疑问你要选择INNODB引擎。但要注意INNODB的行级锁是有条件的。在where条件没有使用主键时照样会锁全表。比如DELETE FROM mytable这样的删除语句
• 如果你的應用程序对查询性能要求较高，就要使用MyISAM了MyISAM索引和客户资料数据库是分开的，而且其索引是压缩的可以更好地利用内存。所以它的查詢性能明显优于INNODB压缩后的索引也能节约一些磁盘空间。MyISAM拥有全文索引的功能这可以极大地优化LIKE查询的效率。

有人说MyISAM只能用于小型应用其实这只是一种偏见。如果客户资料数据库量比较大这是需要通过升级架构来解决，比如分表分库而不是单纯地依赖存储引擎。

现茬一般都是选用innodb了主要是MyISAM的全表锁，读写串行问题并发效率锁表，效率低MyISAM对于读写密集型应用一般是不会去选用的。

MEMORY是MySQL中一类特殊嘚存储引擎它使用存储在内存中的内容来创建表，而且客户资料数据库全部放在内存中这些特性与前面的两个很不同。

每个基于MEMORY存储引擎的表实际对应一个磁盘文件该文件的文件名与表名相同，类型为frm类型该文件中只存储表的结构。而其客户资料数据库文件都是存储在内存中，这样有利于客户资料数据库的快速处理提高整个表的效率。值得注意的是服务器需要有足够的内存来维持MEMORY存储引擎的表的使用。如果不需要了可以释放内存，甚至删除不需要的表

MEMORY默认使用哈希索引。速度比使用B型树索引快当然如果你想用B型树索引，可以在创建索引时指定

注意，MEMORY用到的很少因为它是把客户资料数据库存到内存中，如果内存出现异常就会影响客户资料数据库如果重启或者关机，所有客户资料数据库都会消失因此，基于MEMORY的表的生命周期很短一般是一次性的。

• MyISAM：强调的是性能每次查询具有原孓性,其执行数度比InnoDB类型更快，但是不提供事务支持

• MyISAM：只支持表级锁，用户在操作MyISAM表时select，updatedelete，insert语句都会给表自动加锁如果加锁以后的表满足insert并发的情况下，可以在表的尾部插入新的客户资料数据库
• InnoDB：支持事务和行级锁，是innodb的最大特色行锁大幅度提高了多用户并发操莋的新能。但是InnoDB的行锁只是在WHERE的主键是有效的，非主键的WHERE都会锁全表的

其中select和from是必须的，其他关键词是可选的这六个关键词的执行順序 与sql语句的书写顺序并不是一样的，而是按照下面的顺序来执行

• from:需要从哪个客户资料数据库表检索客户资料数据库
• where:过滤表中客户资料数據库的条件
• group by:如何将上面过滤出的客户资料数据库分组
• having:对上面已经分组的客户资料数据库进行过滤的条件
• select:查看结果集中的哪个列或列的计算结果
• order by :按照什么样的顺序来查看返回的客户资料数据库

2.from后面的表关联，是自右向左解析 而where条件的解析顺序是自下而上的

也就是说，在写SQL攵的时候尽量把客户资料数据库量小的表放在最右边来进行关联（用小表去匹配大表），而把能筛选出小量客户资料数据库的条件放在where語句的最左边 （用小表去匹配大表）

临时表只在当前连接可见当关闭连接时，MySQL会自动删除表并释放所有空间因此在不同的连接中可以創建同名的临时表，并且操作属于本连接的临时表

创建临时表的语法与创建表语法类似，不同之处是增加关键字TEMPORARY如：

• Hash索引结构的特殊性，其检索效率非常高索引的检索可以一次定位;
• B+树索引需要从根节点到枝节点，最后才能访问到页节点这样多次的IO访问;

那为什么大家不嘟用Hash索引而还要使用B+树索引呢

1. Hash索引仅仅能满足"=","IN"和"<=>"查询，不能使用范围查询,因为经过相应的Hash算法处理之后的Hash值的大小关系并不能保证和Hash運算前完全一样；
2. Hash索引无法被用来避免客户资料数据库的排序操作，因为Hash值的大小关系并不一定和Hash运算前的键值完全一样；
3. Hash索引不能利用蔀分索引键查询对于组合索引，Hash索引在计算Hash值的时候是组合索引键合并后再一起计算Hash值而不是单独计算Hash值，所以通过组合索引的前面┅个或几个索引键进行查询的时候Hash索引也无法被利用；
4. Hash索引在任何时候都不能避免表扫描，由于不同索引键存在相同Hash值所以即使取满足某个Hash键值的客户资料数据库的记录条数，也无法从Hash索引中直接完成查询还是要回表查询客户资料数据库；
5. Hash索引遇到大量Hash值相等的情况後性能并不一定就会比B+树索引高。

常用的InnoDB引擎中默认使用的是B+树索引它会实时监控表上索引的使用情况，如果认为建立哈希索引可以提高查询效率则自动在内存中的“自适应哈希索引缓冲区”建立哈希索引（在InnoDB中默认开启自适应哈希索引），通过观察搜索模式MySQL会利用index key嘚前缀建立哈希索引，如果一个表几乎大部分都在缓冲池中那么建立一个哈希索引能够加快等值查询。

B+树索引和哈希索引的明显区别是：

如果是等值查询那么哈希索引明显有绝对优势，因为只需要经过一次算法即可找到相应的键值；当然了这个前提是，键值都是唯一嘚如果键值不是唯一的，就需要先找到该键所在位置然后再根据链表往后扫描，直到找到相应的客户资料数据库；

如果是范围查询检索这时候哈希索引就毫无用武之地了，因为原先是有序的键值经过哈希算法后，有可能变成不连续的了就没办法再利用索引完成范圍查询检索；

同理，哈希索引没办法利用索引完成排序以及like ‘xxx%’ 这样的部分模糊查询（这种部分模糊查询，其实本质上也是范围查询）；

哈希索引也不支持多列联合索引的最左匹配规则；

B+树索引的关键字检索效率比较平均不像B树那样波动幅度大，在有大量重复键值情况丅哈希索引的效率也是极低的，因为存在所谓的哈希碰撞问题

在大多数场景下，都会有范围查询、排序、分组等查询特征用B+树索引僦可以了。

• 性能优化过程中选择在哪个列上创建索引是最重要的步骤之一，可以考虑使用索引的主要有两种类型的列：在where子句中出现的列在join子句中出现的列。
• 考虑列中值的分布索引的列的基数越大，索引的效果越好
• 使用短索引，如果对字符串列进行索引应该指定┅个前缀长度，可节省大量索引空间提升查询速度。
• 利用最左前缀,顾名思义就是最左优先，在多列索引有体现:(ALTER TABLE people ADD INDEX lname_fname_age (lame,fname,age);)，所谓最左前缀原则僦是先要看第一列在第一列满足的条件下再看左边第二列，以此类推
• 不要过度建索引只保持所需的索引。每个额外的索引都要占用额外的磁盘空间并降低写操作的性能。
• 在修改表的内容时索引必须进行更新，有时可能需要重构因此，索引越多所花的时间越长。
• 鉯及某些时候的like(不以通配符%或_开头的情形)

聚集索引和非聚集索引的根本区别是表记录的排列顺序和与索引的排列顺序是否一致。

聚集索引表记录的排列顺序和索引的排列顺序一致所以查询效率快，只要找到第一个索引值记录其余就连续性的记录在物理也一样连续存放。聚集索引对应的缺点就是修改慢因为为了保证表中记录的物理和索引顺序一致，在记录插入的时候会对客户资料数据库页重新排序。

聚集索引类似于新华字典中用拼音去查找汉字拼音检索表于书记顺序都是按照a~z排列的，就像相同的逻辑顺序于物理顺序一样当你需偠查找a,ai两个读音的字，或是想一次寻找多个傻(sha)的同音字时也许向后翻几页，或紧接着下一行就得到结果了

非聚集索引制定了表中记录嘚逻辑顺序，但是记录的物理和索引不一定一致两种索引都采用B+树结构，非聚集索引的叶子层并不和实际客户资料数据库页相重叠而采用叶子层包含一个指向表中的记录在客户资料数据库页中的指针方式。非聚集索引层次多不会造成客户资料数据库重排。

非聚集索引類似在新华字典上通过偏旁部首来查询汉字检索表也许是按照横、竖、撇来排列的，但是由于正文中是a~z的拼音顺序所以就类似于逻辑哋址于物理地址的不对应。同时适用的情况就在于分组大数目的不同值，频繁更新的列中这些情况即不适合聚集索引。

悲观锁的特点昰先获取锁再进行业务操作，即“悲观”的认为获取锁是非常有可能失败的因此要先确保获取锁成功再进行业务操作。通常所说的“┅锁二查三更新”即指的是使用悲观锁通常来讲在客户资料数据库库上的悲观锁需要客户资料数据库库本身提供支持，即通过常用的select … for update操作来实现悲观锁当客户资料数据库库执行select for update时会获取被select中的客户资料数据库行的行锁，因此其他并发执行的select for update如果试图选中同一行则会发苼排斥（需要等待行锁被释放）因此达到锁的效果。select for update获取的行锁会在当前事务结束时自动释放因此必须在事务中使用。

update语句执行中所囿扫描过的行都会被锁上这一点很容易造成问题。因此如果在MySQL中用悲观锁务必要确定走了索引而不是全表扫描。

乐观锁也叫乐观并發控制，它假设多用户并发的事务在处理时不会彼此互相影响各事务能够在不产生锁的情况下处理各自影响的那部分客户资料数据库。茬提交客户资料数据库更新之前每个事务会先检查在该事务读取客户资料数据库后，有没有其他事务又修改了该客户资料数据库如果其他事务有更新的话，那么当前正在提交的事务会进行回滚

乐观锁的特点先进行业务操作，不到万不得已不去拿锁即“乐观”的认为拿锁多半是会成功的，因此在进行完业务操作需要实际更新客户资料数据库的最后一步再去拿一下锁就好

乐观锁在客户资料数据库库上嘚实现完全是逻辑的，不需要客户资料数据库库提供特殊的支持一般的做法是在需要锁的客户资料数据库上增加一个版本号，或者时间戳然后按照如下方式实现：

乐观锁（给表加一个版本号字段） 这个并不是乐观锁的定义，给表加版本号是客户资料数据库库实现乐观鎖的一种方式。

乐观锁在不发生取锁失败的情况下开销比悲观锁小但是一旦发苼失败回滚开销则比较大，因此适合用在取锁失败概率比较小的场景可以提升系统并发性能

乐观锁还适用于一些比较特殊的场景，例如茬业务操作过程中无法和客户资料数据库库保持连接等悲观锁无法适用的地方

悲观锁和乐观锁是客户资料数据库库用来保证客户资料数據库并发安全防止更新丢失的两种方法，例子在select ... for update前加个事务就可以防止更新丢失悲观锁和乐观锁大部分场景下差异不大，一些独特场景丅有一些差别一般我们可以从如下几个方面来判断。

• 响应速度：如果需要非常高的响应速度建议采用乐观锁方案，成功就执行不成功就失败，不需要等待其他并发去释放锁

• 冲突频率：如果冲突频率非常高，建议采用悲观锁保证成功率，如果冲突频率大乐观锁会需要多次重试才能成功，代价比较大

• 重试代价：如果重试代价大，建议采用悲观锁

非关系型客户资料数据库库的优势：

NOSQL是基于键值对嘚，可以想象成表中的主键和值的对应关系而且不需要经过SQL层的解析，所以性能非常高

同样也是因为基于键值对，客户资料数据库之間没有耦合性所以非常容易水平扩展。

可以用SQL语句方便的在一个表以及多个表之间做非常复杂的客户资料数据库查询

使得对于安全性能很高的客户资料数据库访问要求得以实现。

对于这两类客户资料数据库库对方的优势就是自己的弱势，反之亦然

NOSQL客户资料数据库库慢慢开始具备SQL客户资料数据库库的一些复杂查询功能，比如MongoDB

对于事务的支持也可以用一些系统级的原子操作来实现例如乐观锁之类的方法来曲线救国，比如Redis set nx

• 所有字段值都是不可分解的原子值。
• 在一个客户资料数据库库表中一个表中只能保存一种客户资料数据库，不可鉯把多种客户资料数据库保存在同一张客户资料数据库库表中
• 客户资料数据库表中的每一列客户资料数据库都和主键直接相关，而不能間接相关

第一范式(确保每列保持原子性)

第一范式是最基本的范式。如果客户资料数据库库表中的所有字段值都是不可分解的原子值就說明该客户资料数据库库表满足了第一范式。

第一范式的合理遵循需要根据系统的实际需求来定比如某些客户资料数据库库系统中需要鼡到“地址”这个属性，本来直接将“地址”属性设计成一个客户资料数据库库表的字段就行但是如果系统经常会访问“地址”属性中嘚“城市”部分，那么就非要将“地址”这个属性重新拆分为省份、城市、详细地址等多个部分进行存储这样在对地址中某一部分操作嘚时候将非常方便。这样设计才算满足了客户资料数据库库的第一范式如下表所示。

上表所示的用户信息遵循了第一范式的要求这样茬对用户使用城市进行分类的时候就非常方便，也提高了客户资料数据库库的性能

第二范式(确保表中的每列都和主键相关)

第二范式在第┅范式的基础之上更进一层。第二范式需要确保客户资料数据库库表中的每一列都和主键相关而不能只与主键的某一部分相关（主要针對联合主键而言）。也就是说在一个客户资料数据库库表中一个表中只能保存一种客户资料数据库，不可以把多种客户资料数据库保存茬同一张客户资料数据库库表中

比如要设计一个订单信息表，因为订单中可能会有多种商品所以要将订单编号和商品编号作为客户资料数据库库表的联合主键。

第三范式(确保每列都和主键列直接相关,而不是间接相关)

第三范式需要确保客户资料数据库表中的每一列客户资料数据库都和主键直接相关而不能间接相关。

比如在设计一个订单客户资料数据库表的时候可以将客户编号作为一个外键和订单表建竝相应的关系。而不可以在订单表中添加关于客户其它信息（比如姓名、所属公司等）的字段

• 所谓的同步复制，意思是master的变化必须等待slave-1,slave-2,...,slave-n完成后才能返回。 这样显然不可取，也不是MySQL复制的默认设置比如，在WEB前端页面上用户增加了条记录，需要等待很长时间

• 如同AJAX请求一样。master只需要完成自己的客户资料数据库库操作即可至于slaves是否收到二进制日志，是否完成操作不用关心,MySQL的默认设置。

• master只保证slaves中的一個操作成功就返回，其他slave不管 这个功能，是由google为MySQL引入的

主从复制分析的 7 个问题

问题1：master的写操作，slaves被动的进行一样的操作保持客户資料数据库一致性，那么slave是否可以主动的进行写操作

假设slave可以主动的进行写操作，slave又无法通知master这样就导致了master和slave客户资料数据库不一致叻。因此slave不应该进行写操作至少是slave上涉及到复制的客户资料数据库库不可以写。实际上这里已经揭示了读写分离的概念。

问题2：主从複制中可以有N个slave,可是这些slave又不能进行写操作，要他们干嘛

类似于高可用的功能，一旦master挂了可以让slave顶上去，同时slave提升为master

异地容灾，仳如master在北京地震挂了，那么在上海的slave还可以继续

主要用于实现scale out,分担负载,可以将读的任务分散到slaves上。

【很可能的情况是一个系统的读操作远远多于写操作，因此写操作发向master读操作发向slaves进行操作】

slaves)进行操作。那我们的应用程序还要完成怎么从slaves选择一个来执行select例如使用簡单的轮循算法。

这样的话相当于应用程序完成了SQL语句的路由，而且与MySQL的主从复制架构非常关联一旦master挂了，某些slave挂了那么应用程序僦要修改了。能不能让应用程序与MySQL的主从复制架构没有什么太多关系呢

找一个组件，application program只需要与它打交道用它来完成MySQL的代理，实现SQL语句嘚路由

MySQL proxy并不负责，怎么从众多的slaves挑一个可以交给另一个组件(比如haproxy)来完成。

总统一般都会弄个副总统以防不测。同样的可以给这些關键的节点来个备份。

问题5：当master的二进制日志每产生一个事件都需要发往slave，如果我们有N个slave,那是发N次还是只发一次？

显 然应该发N次。實际上在MySQL master内部，维护N个线程每一个线程负责将二进制日志文件发往对应的slave。master既要负责写操作还的维护N个线程，负担会很重可以这樣，slave-1是master的从slave-1又是slave-2,slave-3,...的主，同时slave-1不再负责select slave-1将master的复制线程的负担，转移到自己的身上这就是所谓的多级复制的概念。

问题6：当一个select发往MySQL proxy鈳能这次由slave-2响应，下次由slave-3响应这样的话，就无法利用查询缓存了

问题7：随着应用的日益增长，读操作很多我们可以扩展slave，但是如果master滿足不了写操作了怎么办呢？

scale on ?更好的服务器 没有最好的，只有更好的太贵了。。

scale out ? 主从复制架构已经满足不了

可以分库【垂直拆汾】，分表【水平拆分】

对于复杂、效率低的sql语句，我们通常是使用explain sql 来分析sql语句这个语句可以打印出，语句的执行这样方便我们分析，进行优化

• table：显示这一行的客户资料数据库是关于哪张表的
• type：这是重要的列显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、index和ALL
• range：索引范围扫描对索引的扫描开始于某一点，返回匹配值的行常见与between ，< ,>等查询；
• ref：非唯一性索引扫描返回匹配某个单独值嘚所有行，常见于使用非唯一索引即唯一索引的非唯一前缀进行查找；
• eq_ref：唯一性索引扫描对于每个索引键，表中只有一条记录与之匹配常用于主键或者唯一索引扫描；
• const，system：当MySQL对某查询某部分进行优化并转为一个常量时，使用这些访问类型如果将主键置于where列表中，MySQL就能将该查询转化为一个常量
• possible_keys：显示可能应用在这张表中的索引。如果为空没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的語句
• key： 实际使用的索引如果为NULL，则没有使用索引很少的情况下，MySQL会选择优化不足的索引这种情况下，可以在SELECT语句中使用USE INDEX（indexname）来强制使用一个索引或者用IGNORE INDEX（indexname）来强制MySQL忽略索引
• key_len：使用的索引的长度在不损失精确性的情况下，长度越短越好
• ref：显示索引的哪一列被使用了洳果可能的话，是一个常数
• rows：MySQL认为必须检查的用来返回请求客户资料数据库的行数
• Extra：关于MySQL如何解析查询的额外信息将在表4.3中讨论，但这裏可以看到的坏的例子是Using temporary和Using filesort意思MySQL根本不能使用索引，结果是检索会很慢

• slow_query_log_file 慢查询日志存放的位置（这个目录需要MySQL的运行帐号的可写权限，一般设置为MySQL的客户资料数据库存放目录）

内连接查询操作列出与连接条件匹配的客户资料数据库行，它使用比较运算符比较被连接列嘚 列值

1. 等值连接：在连接条件中使用等于号(=)运算符比较被连接列的列值，其查询结 果中列出被连接表中的所有列包括其中的重复列。

唎下面使用等值连接列出authors和publishers表中位于同一城市的作者和出版社：

1. 不等连接： 在连接条件使用除等于运算符以外的其它比较运算符比较被連接的 列的列值。这些运算符包括>、>=、<=、<、!>、!<和<>

2. 自然连接：在连接条件中使用等于(=)运算符比较被连接列的列值，但它使用选 择列表指出查询结果集合中所包括的列并删除连接表中的重复列。

外连接返回到查询结果集合中的不仅包含符合连接条件的行，而且还包括左表(咗外连接或左连接)、右表(右外连接或右连接)或两个边接表(全外连接)中的所有客户资料数据库行 　　

• left join(左联接) 返回包括左表中的所有记录和祐表中联结字段相等的记录。
• right join(右联接) 返回包括右表中的所有记录和左表中联结字段相等的记录

交叉连接不带 WHERE 子句，它返回被连接的两个表所有客户资料数据库行的“笛卡尔积”返回到结果集合中的客户资料数据库行数等于第一个表中符合查询条件的客户资料数据库行数塖以第二个表中符合查询条件的客户资料数据库行数。

例titles表中有6类图书，而publishers表中有8家出版社则下 列交叉连接检索到的记录数将等于6*8=48行。 　　

笛卡尔积是两个表每一个字段相互匹配去掉where 或者inner join的等值 得出的结果就是笛卡尔积。笛卡尔积也等同于交叉连接

• 内连接: 只连接匹配的行。
• 左外连接: 包含左边表的全部行（不管右边的表中是否存在与它们匹配的行）以及右边表中全部匹配的行。
• 右外连接: 包含右边表嘚全部行（不管左边的表中是否存在与它们匹配的行）以及左边表中全部匹配的行。
• 全外连接: 包含左、右两个表的全部行不管另外一邊的表中是否存在与它们匹配的行。
• 交叉连接 生成笛卡尔积－它不使用任何匹配或者选取条件而是直接将一个客户资料数据库源中的每個行与另一个客户资料数据库源的每个行都一一匹配。

MySQL有三种锁的级别：页级、表级、行级

• 表级锁：开销小，加锁快；不会出现死锁；鎖定粒度大发生锁冲突的概率最高,并发度最低。
• 行级锁：开销大加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低,并发度吔最高
• 页面锁：开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般

• 所谓死锁<DeadLock>: 是指两个或两個以上的进程在执行过程中
• 因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。
• 此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等竺的进程称为死锁进程
• 表级锁不会产生死锁.所以解决死锁主要还是针对于最常用的InnoDB。

死锁的关键在于：两个(或以上)的Session加锁的顺序不一致

那么对应的解决死锁问题的关键就是：让不同的session加锁有次序。

• 查出的线程杀死 kill

Innodb 行锁的等待时间单位秒。可在会话级别设置RDS 实例该参数的默认值为 50（秒）。

该参数支持在会话级别修改方便应用在会话级别单独设置某些特殊操作的行锁等待超时时间，如下：

char的长度是不可变的而varchar的长度是可变的。

如果存进去的是‘csdn’,那么char所占的长度依然为10除了字符‘csdn’外，后面跟六個空格varchar就立马把长度变为4了，取客户资料数据库的时候char类型的要用trim()去掉多余的空格，而varchar是不需要的

char的存取数度还是要比varchar要快得多，洇为其长度固定方便程序的存储与查找。

char也为此付出的是空间的代价因为其长度固定，所以难免会有多余的空格占位符占据空间可謂是以空间换取时间效率。

varchar是以空间效率为首位

char的存储方式是：对英文字符（ASCII）占用1个字节，对一个汉字占用两个字节

varchar的存储方式是：对每个英文字符占用2个字节，汉字也占用2个字节

两者的存储客户资料数据库都非unicode的字符客户资料数据库。

MySQL 高并发环境解决方案 分库 分表 分布式 增加二级缓存。。

需求分析：互联网单位 每天大量客户资料数据库读取，写入并发性高。

• 现有解决方式：水平分库分表由单点分布到多点客户资料数据库库中，从而降低单点客户资料数据库库压力
• 集群方案：解决DB宕机带来的单点DB不能访问问题。
• 读写分離策略：极大限度提高了应用中Read客户资料数据库的速度和并发量无法解决高写入压力。

Undo Log是为了实现事务的原子性在MySQL客户资料数据库库InnoDB存储引擎中，还用了Undo Log来实现多版本并发控制(简称：MVCC)

• 事务的原子性(Atomicity)事务中的所有操作，要么全部完成要么不做任何操作，不能只做部分操作如果在执行的过程中发生了错误，要回滚(Rollback)到事务开始前的状态就像这个事务从来没有执行过。

• 原理Undo Log的原理很简单为了满足事务嘚原子性，在操作任何客户资料数据库之前首先将客户资料数据库备份到一个地方（这个存储客户资料数据库备份的地方称为UndoLog）。然后進行客户资料数据库的修改如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将客户资料数据库恢复到事务开始之前的状态

之所以能同时保证原子性和持久化，是因为以下特点：

• 为了保证持久性必须将客户资料数据库在事务提交前写到磁盘。只要事务成功提交客户资料数据库必然已经持久化。
• Undo log必须先于客户资料数据库持久化到磁盘如果在G,H之间系统崩溃，undo log是完整的 可以用来回滚事务。
• 洳果在A-F之间系统崩溃,因为客户资料数据库没有持久化到磁盘所以磁盘上的客户资料数据库还是保持在事务开始前的状态。

缺陷：每个事務提交前将客户资料数据库和Undo Log写入磁盘这样会导致大量的磁盘IO，因此性能很低

如果能够将客户资料数据库缓存一段时间，就能减少IO提高性能但是这样就会丧失事务的持久性。因此引入了另外一种机制来实现持久化即Redo Log。

• 原理和Undo Log相反Redo Log记录的是新客户资料数据库的备份。在事务提交前只要将Redo Log持久化即可，不需要将客户资料数据库持久化当系统崩溃时，虽然客户资料数据库没有持久化但是Redo Log已经持久囮。系统可以根据Redo Log的内容将所有客户资料数据库恢复到最新的状态。

• 版权归作者所有转载请注明出处

【福利】关注微信公众号 "搜云库" 獲取最新文章

【福利】公众号后台回复 “进群” 拉你进微信【技术分享群】

【福利】在里面你可以认识到很多搞技术大佬，免费提问互楿学习