InnoDB

一个成熟的数据库架构并不是一开始设计就具备高可用、高伸缩等特性的，它是随着用户量的增加，基础架构才逐渐完善。这篇博文主要谈MySQL数据库发展周期中所面临的问题及优化方案，暂且抛开前端应用不说，大致分为以下五个阶段： 1、数据库表设计 项目立项后，开发部根据产品部需求开发项目，开发工程师工作其中一部分就是对表结构设计。对于数据库来说，这点很重要，如果设计不当，会直接影响访问速度和用户体验。影响的因素很多，比如慢查询、低效的查询语句、没有适当建立索引、数据库堵塞（死锁）等。当然，有测试工程师的团队，会做压力测试，找bug。对于没有测试工程师的团队来说，大多数开发工程师初期不会太多考虑数据库设计是否合理，而是尽快完成功能实现和交付，等项目有一定访问量后，隐藏的问题就会暴露，这时再去修改就不是这么容易的事了。 2、数据库部署 该运维工程师出场了，项目初期访问量不会很大，所以单台部署足以应对在1500左右的QPS（每秒查询率）。考虑到高可用性，可采用MySQL主从复制+Keepalived做双击热备，常见集群软件有Keepalived、Heartbeat。 双机热备博文：http://lizhenliang.blog.51cto.com/7876557/1362313 3、数据库性能优化 如果将MySQL部署到普通的X86服务器上，在不经过任何优化情况下

01 MySQL索引 MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，哈希索引，全文索引等等。为了避免混乱，本文将只关注于BTree索引，因为这是平常使用MySQL时主要打交道的索引。 MySQL官方对索引的定义为： 索引（Index）是帮助MySQL高效获取数据的数据结构。 提取句子主干，就可以得到索引的本质： 索引是数据结构。 02 MySQL索引原理 1、索引目的 索引的目的在于提高查询效率，可以类比字典，如果要查“mysql”这个单词，我们肯定需要定位到m字母，然后从下往下找到y字母，再找到剩下的sql。如果没有索引，那么你可能需要把所有单词看一遍才能找到你想要的，如果我想找到m开头的单词呢？或者ze开头的单词呢？是不是觉得如果没有索引，这个事情根本无法完成？ 咱们去图书馆借书也是一样，如果你要借某一本书，一定是先找到对应的分类科目，再找到对应的编号，这是生活中活生生的例子，通用索引，可以加快查询速度，快速定位。 2、索引原理 所有索引原理都是一样的，通过不断的缩小想要获得数据的范围来筛选出最终想要的结果，同时把随机的事件变成顺序的事件，也就是我们总是通过同一种查找方式来锁定数据。 数据库也是一样，但显然要复杂许多，因为不仅面临着等值查询，还有范围查询(>、<、between)、模糊查询(like)

实际工作中，有时候打开一个页面响应时间非常慢，这背后通常牵涉到SQL语句查询慢的问题。 前面我们提到很多数据库结构设计，建索引等来视图提高MySQL的性能。但是如果我们实际业务场景中，SQL查询语句写的不合适，索引建的再好可能也达不到预期的高性能。 因此，我们很有必要对查询进行分析，我写的查询为什么慢，该怎么样对查询进行优化。 关于 MySQL 相关的内容，Alibaba肯定还是很有话语权的，尤其是关于 MySQL的使用 ，所以今天我们要分享的内容，实际上就是 Alibaba顶级MySQL调优手册 ，看完你也不得不感叹这份 极品手册 啊！ 由于文章篇幅有限，下文中的内容只展示这份手册的目录以及部分内容截图， MySQL高级调优笔记主要内容 由于文档内容过多，因此为了避免影响到大家的阅读体验，在此只以截图展示部分内容，详细完整版的 看文末有免费的获取方式！ 第一部分 : MySQL 常用对象 Linux安装MySQL及启动 MySQL对象 - 索引 MySQL对象 - 视图 MySQL对象 - 存储过程 MySQL对象 - 触发器 第二部分 : MySQL体系结构,存储引擎及SQL优化 MySQL 体系结构 MySQL 存储引擎 MySQL 优化步骤 MySQL 索引的使用 MySQL - SQL优化 第三部分 : MySQL缓存,参数调整及锁 MySQL - 应用优化 MySQL

Java技术栈 www.javastack.cn 关注阅读更多优质文章 作者：小小木的博客 www.cnblogs.com/wyc1994666/p/10831039.html 开门见山，直接上图，下面的思维导图即是现在要讲的内容，可以先有个印象～ 常见索引类型(实现层面) 索引种类(应用层面) 聚簇索引与非聚簇索引 覆盖索引 最佳索引使用策略 1.常见索引类型(实现层面) 首先不谈Mysql怎么实现索引的,先马后炮一下,如果让我们来设计数据库的索引，该怎么设计？ 我们首先思考一下索引到底想达到什么效果？其实就是想能够实现 快速查找 数据的策略，所以索引的实现本质上就是一个 查找算法 。 但是跟普通的查找有所不同，因为我们的数据有一下特征： 1.存储的数据是非常非常多的 2.并且还不断的动态变化 所以实现索引时需要考虑到这两个特点。我们需要找一个最合适的数据结构算法来实现查找功能。 下面一起看下常见的查找策略，如下图： 由于前面说的两个特点我们首先排除静态查找的算法。 至于查找树，我们有二叉树和多叉树两种选择： 二叉树 ：如果先泽二叉树的话，由于我们的数据量庞大，二叉树的深度会变得非常大，我们的索引树会变成参天大树，每次查询会导致很多磁盘IO。 多叉树 ：多叉树解决了了树的深度大的问题，那么我们到底选择B树还是B+树呢？ B树 摘自维基百科 https://zh.wikipedia

Java技术栈 www.javastack.cn 关注阅读更多优质文章 来源：小小木的博客 www.cnblogs.com/wyc1994666/p/11367051.html 开篇 相信大家都用过事务以及了解他的特点，如原子性(Atomicity),一致性(Consistency),隔离型(Isolation)以及持久性(Durability)等。今天想跟大家一起研究下事务内部到底是怎么实现的，在讲解前我想先抛出个问题： 事务想要做到什么效果？ 按我理解，无非是要做到 可靠性 以及 并发处理 可靠性：数据库要保证当insert或update操作时抛异常或者数据库crash的时候需要保障数据的操作前后的一致，想要做到这个，我需要知道我修改之前和修改之后的状态，所以就有了undo log和redo log。 并发处理：也就是说当多个并发请求过来，并且其中有一个请求是对数据修改操作的时候会有影响，为了避免读到脏数据，所以需要对事务之间的读写进行隔离，至于隔离到啥程度得看业务系统的场景了，实现这个就得用MySQL 的隔离级别。 下面我首先讲实现事务功能的三个技术，分别是日志文件(redo log 和 undo log)，锁技术以及MVCC，然后再讲事务的实现原理，包括原子性是怎么实现的，隔离型是怎么实现的等等。最后在做一个总结，希望大家能够耐心看完 redo log与undo log介绍

1.MySQL管理 1.1启动和关闭服务 # Linux service mysqld start # 启动 service mysqld stop # 关闭 service mysql restart # 重启 # Windows net start mysql # 启动 net stop mysql # 关闭 1.2常用命令 登录 mysql -u root -p[密码] [-P端口] [-h地址] USE 数据库名 列出 MySQL 数据库管理系统的数据库列表 mysql> USE sql_test; Database changed SHOW DATABASES: 列出 MySQL 数据库管理系统的数据库列表 mysql> SHOW DATABASES; +--------------------+ | Database | +--------------------+ | information_schema | | mysql | | performance_schema | | sys | +--------------------+ 4 rows in set (0.00 sec) SHOW TABLES: 显示指定数据库的所有表，使用该命令前需要使用 use 命令来选择要操作的数据库 mysql> SHOW TABLES; +-------------------

前几天下班回到家后正在处理一个白天没解决的bug，厕所突然传来对象的声音： 对象：xx，你有《时间简史》吗？ 我：我去！妹子，你这啥癖好啊，我有时间也不会去捡屎啊！ 对象：...人家说的是霍金的科普著作《时间简史》，是一本书啦！ 我：哦，那我没有... 对象：人家想看诶，你明天帮我去图书馆借一本吧... 我：我明天还要改... 对象：你是不是不爱我了，分手！ 我：我一大早就去~   第二天一大早我就到了图书馆，刚进门就看到一个索引牌，标识着不同楼层的功能，这样我很快能定位到我要找的目标所在的楼层了。      我到楼上后又看到每排的书架上又对书的分类进行了细分，这样我能更快的定位到我要找的书具体在哪个书架！   并且每个楼层都有一台查询终端，输入书名就能查到对应的唯一标识“索书号”，类似于P159-49/164这样的一个编码，书架上的书都是按照这个编码进行排序的！有了这个编码再去对应的书架上，很快就能找到对应的书在书架的具体位置了。      不到十分钟，我就从图书馆借好书出来了。   这么大的图书馆，我为什么能在这么短的时间内找到我要的书？如果这些书是杂乱无章的堆放，或者没有任何标识的放在书架，我还能这么快的找到吗？   这不禁让我想到了我们开发中用到的数据库，图书馆的书就类似我们数据表中的数据，楼层索引牌、书架分类标识、索书号就类似我们查找数据的索引。  

https://blog.csdn.net/aesop_wubo/article/details/8286215 * CREATE TABLE `user_item` ( * `id` BIGINT(20) NOT NULL, * `user_id` BIGINT(20) NOT NULL, * `item_id` BIGINT(20) NOT NULL, * `status` TINYINT(4) NOT NULL, * PRIMARY KEY (`id`), * KEY `idx_1` (`user_id`,`item_id`,`status`) * ) ENGINE=INNODB DEFAULT CHARSET=utf-8 Mysql innodb存储引擎行级锁是锁索引，如果表上没有用到索引则变为表级锁，如果用到主键索引则先锁主键后锁其他索引，如果没有用到主键索引，则先锁其他索引，再锁主键索引，高并发更新一定要带上主键，优先获得主键上的锁，防止死锁 上表中包含了`id`为聚簇主键索引，`idx_1`为非主键索引，如果一条SQL包含了主键索引，则锁定主键索引，如果包含非主键索引，则先锁定非主键索引，再锁定主键索引。 下面的SQL用到了非主键索引`idx_1`，所以先锁住非主键索引再锁主索引 update user_item set status=1 where user_id=