本文中说到的“建”，并非单纯的建一个库，或是建一张表，而是你建好的库和表在项目的运营中，是否能应付各种事件，下面我说说几个我在项目中遇到的问题以及处理的方法，算是一个小小的心得，给大家分享下。
最近有一些朋友问我一些mysql相关的面试题，有一些比较基础，有些比较偏。这里就总结一些常见的mysql面试题吧，都是自己平时工作的总结以及经验。大家看完，能避开很多坑。而且很多问题，都是面试中也经常问到！希望能对大家的面试有一些帮助！！！
MySQL的优化主要分为结构优化（Scheme optimization）和查询优化（Query optimization）。本章讨论的高性能索引策略主要属于结构优化范畴。本章的内容完全基于上文的理论基础，实际上一旦理解了索引背后的机制，那么选择高性能的策略就变成了纯粹的推理，并且可以理解这些策略背后的逻辑。
学习MySQL的知识，学习好索引是非常重要的，索引分类、索引如何正确添加、索引失效的场景、底层数据结构等问题是面试中必问的，就这些内容我们一起学习巩固下。
在InnoDB中我们可能会遇到死锁，一般情况下我们对于死锁无需关注，MySQL会自己处理，不过如果我们在error日志中发现大量的死锁，就需要我们检查应用并进行相应的处理
其实上面这些问题，我最早想法是，每个问题都可以啰嗦出一篇文章。后来由于良心发现，烟哥就决定用一篇文章将这些问题都讲明白。 当然，我给的回答可能并非标准答案，毕竟是自己的一些工作总结。各位读者有更好的回答，也欢迎交流！
大家有没有遇到过慢查询的情况，执行一条SQL需要几秒，甚至十几、几十秒的时间，这时候DBA就会建议你去把查询的 SQL 优化一下，怎么优化？你能想到的就是加索引吧？
执行 select * from T where k between 3 and 5，需要几次树的搜索，扫描多少行？
约束条件：限制表中的数据，保证添加到数据表中的数据准确和可靠性！凡是不符合约束的数据，插入时就会失败！ 约束条件在创建表时可以使用， 也可以修改表的时候添加约束条件
（下面这张图为计算机组成原理内容，每查询一次索引节点，都会进行一次磁盘IO读取，即要寻道和旋转）
在mysql运维操作中会经常使用到alter这个修改表的命令，alter tables允许修改一个现有表的结构，比如增加或删除列、创造或消去索引、改变现有列的类型、或重新命名列或表本身，也能改变表的注释和表的类型。 下面就针对alter修改命令的使用做一梳理： 在mysql运维操作中会经常使用到alter这个修改表的命令，alter tables允许修改一个现有表的结构，比如增加或删除列、创造或消去索引、改变现有列的类型、或重新命名列或表本身，也能改变表的注释和表的类型。 下面就针对alter修改命令的使用
出于习惯，我们一般会加一列id作为主键，而这个主键一般边上都有个AUTO_INCREMENT, 意思是这个主键是自增的。自增就是i++，也就是每次都加1。
为了保证数据的完整性，SQL规范以约束的方式对表数据进行额外的条件限制。从以下四个方面考虑：
1、因为任何有业务含义的列都有改变的可能性,主键一旦带上了业务含义，那么主键就有可能发生变更。主键一旦发生变更，该数据在磁盘上的存储位置就会发生变更，有可能会引发页分裂，产生空间碎片。
今天下午对比了下MyCAT，MySQL和其他数据库的能力项对比情况，梳理了一个列表，因为篇幅原因，主要包含如下的一些能力项。
大家好我是北哥，今天整理了MySQL索引相关的知识点及面试常见问题及答案，分享给大家。 以下问题及答案没有特殊说明默认都是针对InnoDB存储引擎，如有不对的地方可以留言讨论哦~ 什么是索引？
这是为什么呢？ 原因： 现在使用MySQL基本默认指的InnoDB引擎，InnoDB是聚集索引表，所有的数据按主键排序存储。所以对于从小到大的数据做主键插入不会引起数据页的拆分，可以实现数据高效的写入，另一方面普通索引包含主键存储，所以要求主键尽可能的短小，减少空间的浪费。 对于使用自增列(int 4byte,bigint 8byte）,如果使用uuid产生的是一个无序的36byte的字符（前面是乱的），造成写入的性能会越来越差，表的数据量在1000万以内，可能性能差别还不大。
使用过inception的人对SQL审核这块获取都比较熟悉，作为DBA，审核SQL是日常工作中的很重要的一块内容，审核好SQL对于后期项目以及数据库维护上起着至关重要的作用，好比一座大厦没有坚实的地基支撑，也就无法长期屹立不倒。
MySQL中，索引属于存储引擎级别的概念，不同存储引擎对索引的实现方式是不同的，我们这里主要讨论MyISAM和InnoDB两个存储引擎的索引实现方式。
unique、 primary key、not null、default相对简单，本篇文章不做记录。
数据完整性（Data Integrity）是指数据的精确性（Accuracy）和可靠性（Reliability）。它是防止数据库中存在不符合语义规定的数据和防止因错误信息的输入输出造成无效操作或错误信息而提出的。
查询是数据库的最主要功能之一。我们都希望查询速度能尽可能快，因此数据库系统的设计者会从查询算法角度优化
本文以MySQL数据库为研究对象，讨论与数据库索引相关的一些话题。特别需要说明的是，MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，哈希索引，全文索引等等。为了避免混乱，本文将只关注于BTree索引，因为这是平常使用MySQL时主要打交道的索引，至于哈希索引和全文索引本文暂不讨论。
在笔者支持业务过程中，经常遇到开发咨询replace into 的使用场景以及注意事项，这里做个总结。从功能原理，性能和注意事项上做个说明。
今天我们来说一下我们的mysql，个人认为现在的mysql能做到很好的优化处理，不比收费的oracle差，而且mysql确实好用。
数据库优化有很多可以讲，按照支撑的数据量来分可以分为两个阶段：单机数据库和分库分表，前者一般可以支撑500W或者10G以内的数据，超过这个值则需要考虑分库分表。另外，一般大企业面试往往会从单机数据库问起，一步一步问到分库分表，中间会穿插很多数据库优化的问题。本文试图描述单机数据库优化的一些实践，数据库基于mysql，如有不合理的地方，欢迎指正。
Navicat Premium for Mac的破解教程 注意时间戳是今天的时间-2019-02-20 12:00:00
一般用磁盘IO评价索引结构的优劣。B-树检索一次，最多访问h个节点，即其时间复杂度O(h)=O(log_d N),其实红黑色O(h)=O(log_2 N),接下来以实际数据做对比：数据量640亿。
索引是一种帮助mysql高效的获取数据的数据结构，这些数据结构以某种方式引用数据，这种结构就是索引。可简单理解为排好序的快速查找数据结构。如果要查“mysql”这个单词，我们肯定需要定位到m字母，然后从下往下找到y字母，再找到剩下的sql。
单主模式：只有一个成员对外提供服务。单主模式和异步模式比较类似，有了主从复制的经验，维护单主模式的MGR其实并不难，下面的图说明了单主模式下的一些特点：
摘要 本文以MySQL数据库为研究对象，讨论与数据库索引相关的一些话题。特别需要说明的是，MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，哈希索引，全文索引等等。为了避免混乱，本文将只关注于BTree索引，因为这是平常使用MySQL时主要打交道的索引，至于哈希索引和全文索引本文暂不讨论。 文章主要内容分为三个部分。 第一部分主要从数据结构及算法理论层面讨论MySQL数据库索引的数理基础。 第二部分结合MySQL数据库中MyISAM和
面试官：咱们聊聊mysql的自增id。mysql自增id给我们的自增主键定义带来了很大的方便，但是经常mysql的自增id会有不连续情况，能说说什么场景下mysql的id会产生不连续吗我：我以一张表为例来解释一下，我先创建一张表zh_person，这张表包括4个字段，自增id，姓名name，性别sex和身份证号id_no,id_no上有唯一索引，sql如下 CREATE TABLE `zh_person` ( `id` MEDIUMINT(11) NOT NULL AUTO_INCREMENT, `
在数据库中对表中的数据进行限制，保证数据的正确性、有效性和完整性。一个表如果添加了约束，不正确的数据将无法插入到表中。约束在创建表的时候添加比较合适。
1、如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择主键作为聚集索引、如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引、如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增，这个ROWID不像ORACLE的ROWID那样可引用，是隐含的)。
1、如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择主键作为聚集索引。如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引。如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增，这个ROWID不像ORACLE的ROWID那样可引用，是隐含的)。
二、MYSQL数据库设计原则 1、核心原则 不在数据库做运算; cpu计算务必移至业务层; 控制列数量(字段少而精,字段数建议在20以内); 平衡范式与冗余(效率优先；往往牺牲范式) 拒绝3B(拒绝大sql语句：big sql、拒绝大事务：big transaction、拒绝大批量：big batch); 2、字段类原则 用好数值类型(用合适的字段类型节约空间); 字符转化为数字(能转化的最好转化,同样节约空间、提高查询性能); 避免使用NULL字段(NULL字段很难查询优化、NULL字段的索引需要额外空
1、如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择主键作为聚集索引。
本系列文章将整理到我在GitHub上的《Java面试指南》仓库，更多精彩内容请到我的仓库里查看
UUID 是 通用唯一识别码（Universally Unique Identifier）的缩写，是一种软件建构的标准，亦为开放软件基金会组织在分布式计算环境领域的一部分。其目的，是让分布式系统中的所有元素，都能有唯一的辨识信息，而不需要通过中央控制端来做辨识信息的指定。如此一来，每个人都可以创建不与其它人冲突的UUID。在这样的情况下，就不需考虑数据库创建时的名称重复问题。目前最广泛应用的UUID，是微软公司的全局唯一标识符（GUID），而其他重要的应用，则有Linux ext2/ext3文件系统、LUKS加密分区、GNOME、KDE、Mac OS X等等。另外我们也可以在e2fsprogs包中的UUID库找到实现。
分库分表在数据量大的系统中比较常用，解决方案有Cobar，TDDL等，这次主要是拿当当网开源的Sharding-JDBC来做个小例子。 它的github地址为：https://github.com/dangdangdotcom/sharding-jdbc 简介： Sharding-JDBC直接封装JDBC API，可以理解为增强版的JDBC驱动，旧代码迁移成本几乎为零： 可适用于任何基于java的ORM框架，如：JPA, Hibernate, Mybatis, Spring JDBC Template或直接使用JDBC。 可基于任何第三方的数据库连接池，如：DBCP, C3P0, BoneCP, Druid等。 理论上可支持任意实现JDBC规范的数据库。虽然目前仅支持MySQL，但已有支持Oracle，SQLServer，DB2等数据库的计划。 Sharding-JDBC定位为轻量级java框架，使用客户端直连数据库，以jar包形式提供服务，未使用中间层，无需额外部署，无其他依赖，DBA也无需改变原有的运维方式。SQL解析使用Druid解析器，是目前性能最高的SQL解析器。 具体的介绍可以上它的文档那里看看，简单归纳起来就是，它是一个增强版的JDBC，对使用者透明，逻辑代码什么的都不用动，它来完成分库分表的操作；然后它还支持分布式事务（不完善）。看起来很不错的样子。 下面用个小例子来看一下分库分表的使用。使用的是SpringBoot，JPA（hibernate），druid连接池。
索引是MySQL数据库中的重要对象之一，索引的目的在于提高查询效率。可以类比字典中的目录，查找字典内容时可以根据目录查找到数据的存放位置，然后直接获取即可。索引是表的目录，在查找内容之前可以先在目录中查找索引位置，以此快速定位查询数据。需要说明的是，MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同。为了避免混乱，本文将只关注于InnoDB引擎下的B+Tree索引。
1. 主：binlog线程——记录下所有改变了数据库数据的语句，放进master上的binlog中；
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
Metric:mysql.innodb_row_lock_waits Tags:port=4306,service=xxxx diff(#1): 996>900
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
