索引

说实话，这个问题可以涉及到 MySQL 的很多核心知识，可以扯出一大堆，就像要考你计算机网络的知识时，问你“输入URL回车之后，究竟发生了什么”一样，看看你能说出多少了。 之前腾讯面试的实话，也问到这个问题了，不过答的很不好，之前没去想过相关原因，导致一时之间扯不出来。所以今天，我带大家来详细扯一下有哪些原因，相信你看完之后一定会有所收获，不然你打我。 开始装逼：分类讨论 一条 SQL 语句执行的很慢，那是每次执行都很慢呢？还是大多数情况下是正常的，偶尔出现很慢呢？所以我觉得，我们还得分以下两种情况来讨论。 1、大多数情况是正常的，只是偶尔会出现很慢的情况。 2、在数据量不变的情况下，这条SQL语句一直以来都执行的很慢。 针对这两种情况，我们来分析下可能是哪些原因导致的。 针对偶尔很慢的情况 一条 SQL 大多数情况正常，偶尔才能出现很慢的情况，针对这种情况，我觉得这条SQL语句的书写本身是没什么问题的，而是其他原因导致的，那会是什么原因呢？ 数据库在刷新脏页我也无奈啊 当我们要往数据库插入一条数据、或者要更新一条数据的时候，我们知道数据库会在 内存 中把对应字段的数据更新了，但是更新之后，这些更新的字段并不会马上同步持久化到 磁盘 中去，而是把这些更新的记录写入到 redo log 日记中去，等到空闲的时候，在通过 redo log 里的日记把最新的数据同步到 磁盘 中去。 不过

Oracle对象的操作 启动Oracle 1、启动监听(想要oracle能够远程访问到必须配置监听) 2、启动数据库 1）登录服务器，切换到Oracle用户 2）打开监听服务 lsnrctl start 3）以sys用户身份登录Oracle sqlplus /nolog conn /as sysdba; 4）通过startup命令启动 关闭Oracle 1）关闭数据库shutdown 2）关闭监听器lsnrctl stop 一、用户 1、查看所有用户： select * from dba_users; select * from all_users; select * from user_users; 2、创建用户： create user 用户名 identified by 密码; 注意刚刚创建的用户是没有任何权限的，因此需要dba给该用户进行授权； Oracle中用户建立之后是无法正常登录的，只有dba对用户分配相关的权限之后用户才可以登录。 3、给用户分配权限 grant 权限 to 用户名; 权限分为系统权限和对象权限 系统权限是数据库管理相关的权限 系统权限：create session(登录权限)、create table(创建表权限)、create index(创建索引的权限)、create view(创建视图权限)、create sequence(创建序列权限)

一、表设计优化 　　1、简单既优 　　　　数组和字符要给范围，不易过长过大 　　　　时间尽量使用时间戳格式，占用的存储空间比较少 　　　　字段和表注释必不可少 　　2、索引设置 　　　　常用查询字段要添加索引 　　　　如果能使用联合索引代替的尽量使用联合索引代替 　　3、合适的表引擎 　　　　myisam更适合读写较快的地方 　　　　innodb更适合处理事务和更新删除 二、查询优化 　　1、范查询最好禁止 　　　　查询字段要具体，尽量避免使用* 　　2、尽可能使用索引 　　　　根据不同索引，查询时最好使用索引 　　3、exists和in使用特点 　　　　如果查询的两个表大小相当，那么用in和exists效率差别不大 　　　　如果两个表中一个较小，一个较大，则子查询表大的用exists，子查询表小的用in 三、数据量过高优化 　　1、分区分表，mysql5.5之后分区逐渐代替了分表 　　2、主从设置，可以一主多从和多主多从 四、sql分析 　　1、explain 后面跟sql语句 　　主要的字段 type，rows，keys ； 　　　　type指定了该sql使用那种类型的查询 　　　　keys知道了该sql使用了那些索引 　　　　rows知道了查询结果需要遍历多少行才可以得到结果 五、常见mysql配置 　　错误日志 　　　log-error= dir 　　慢查询 　　　

1.什么是覆盖索引 如果一个索引包含所需要查询的字段，无需回表，则称为‘覆盖索引’。 2.什么是回表操作 简单来说就是数据库根据索引（非主键）找到了指定的记录所在行后，还需要根据主键再次到数据块里获取数据。 来源： CSDN 作者： houxinhong 链接： https://blog.csdn.net/houxinhong/article/details/104747070

场景分析 由于公司zabbix的历史数据存储在elasticsearch中，有个需求是尽可能地把监控的历史数据存储的长一点，最好是一年，目前的情况是三台ES节点，每天监控历史数据量有5G，目前最多可存储一个月的数据，超过30天的会被定时删除，每台内存分了8G，且全部使用机械硬盘，主分片为5，副本分片为1，查询需求一般只获取一周的历史数据，偶尔会有查一个月到两个月历史数据的需求。 节点规划 为了让ES能存储更长的历史数据，以及考虑到后续监控项添加导致数据的增长，我将节点数量增加至4节点，并将部分节点内存提高，部分节点采用SSD存储 192.168.179.133 200GSSD 4G内存 tag:hot node.name=es1 192.168.179.134 200GSSD 4G内存 tag:hot node.name=es2 192.168.179.135 1THDD 32G内存 tag:cold node.name=es3 node.master=false 192.168.179.136 1THDD 32G内存 tag:cold node.name=es4 node.master=false 优化思路 对数据mapping重新建模，对str类型的数据不进行分词，采用冷热节点对数据进行存储，前七天数据的索引分片设计为2主1副，索引存储在热节点上，超过七天的数据将被存储在冷节点

场景分析 由于公司zabbix的历史数据存储在elasticsearch中，有个需求是尽可能地把监控的历史数据存储的长一点，最好是一年，目前的情况是三台ES节点，每天监控历史数据量有5G，目前最多可存储一个月的数据，超过30天的会被定时删除，每台内存分了8G，且全部使用机械硬盘，主分片为5，副本分片为1，查询需求一般只获取一周的历史数据，偶尔会有查一个月到两个月历史数据的需求。 节点规划 为了让ES能存储更长的历史数据，我将节点数量增加至4节点，并将部分节点内存提高，部分节点采用SSD存储 192.168.179.133 200GSSD 4G内存 tag:hot node.name=es1 192.168.179.134 200GSSD 4G内存 tag:hot node.name=es2 192.168.179.135 500GHDD 64G内存 tag:cold node.name=es3 192.168.179.136 500GHDD 64G内存 tag:cold node.name=es4 优化思路 对数据mapping重新建模，对str类型的数据不进行分词，采用冷热节点对数据进行存储，前七天数据的索引分片设计为2主1副，索引存储在热节点上，超过七天的数据将被存储在冷节点，并修改冷节点上的副本分片数为0，ES提供了一个shrink的api来进行压缩

基本SQL命令 库管理 创建库（指定字符集）:create database 库名 default charset = utf-8; 查看创建库的语句:show create database 库名； 切换库:use 库名； 查看当前所在库：select database(); 查看库中已有表:show tables; 删除库：drop database 库名； 表管理 创建表（指定字符集）:CREATE TABLES 表名(字段名，数据类型，...)DEFAULT CHARSET = UTF-8; 查看创建表的语句(字符集和存储引擎)：show create table 表名； 查看表结构：desc 表名； 删除表：drop table 表名； 表记录管理： 插入：insert into 表名 values(),(),...; insert into 表名(字段名列表) values(),(),...; 查询：select * from 表名； select 字段名1，字段名2，...from 表名； 删除：delete from 表名 where 条件； 更新：update 表名 set 字段名=值1,...where 条件； 表字段管理： 添加：alter table 表名 add 字段名 数据类型 first ； alter table 表名 add 字段名 数据类型

昨天晚上看探索栏目， 深海捕捞帝王蟹；在遥远的阿拉斯加，捕捞船若捞上来的是 母蟹会全部重新放到海里 ，每个人手上拿了一个尺子， 若尺寸没达标的公蟹会重新放到大海 里，邪恶的美国你为什么这么强大、我愿意当个幸福的母蟹、但是千万不要把我生在邪恶的东海， 曾经从来没想移民的愿望，看了这期探险节目后，更加懂了什么叫爱护环境爱护地球了。我们的东海别说螃蟹，好像连虾米都被电死得差不多了干得竟都是断子绝孙的事儿，邪恶的美帝你太强大了。希望我们不要成为人类的害虫。 我们可以无知，但是不能愚昧，不能干太多断子绝孙的事情，保护我们生存环境从你我做起。 好久没写博客了，一方面是日常工作繁忙，另外一方面是想更多的时间陪陪家里人，享受春天的美好时光，还在写一本 《程序员，你伤不起》 的一本书要由人民邮电出版社出版；我的性格可能也跟大多数程序员类似吧，没什么兴趣爱好、不擅长与人交流、平时话也少、也不够幽默，唯一的优点就是一个实实在在。 下图命名为：孤独的程序员 其实真正优化信息化系统的核心，还是要靠优化那些SQL语句，当然顶尖高手写的SQL语句没多少可优化的余地，毕竟不是人人都是工作10年以上的资深软件开发人员，有时候由于忙、事情紧急、或者没充分考虑业务逻辑，或者根本没想到网站从一个无名小站变成行业出名的站点。平时事情也是千头万绪只要服务器在能抗得过就没怎么关注吧。 最近我看了主服务器的SQL语句耗时比较多

开心一刻 　　楼主：来，我们先排练一遍 　　小伙伴们：好 　　嘿、哈、嚯 　　楼主：非常好，就是这个节奏，我们开始吧 　　楼主：啊、啊、啊，疼 ！ 你们是不是故意的 ？ 回表与覆盖索引 　　正式讲 ICP 之前了，我们先将相关的概念捋一捋，知道的就当回顾，不知道的就当了解了，这有助于对 ICP 的理解 　　建个示例表 tbl_index CREATE TABLE tbl_index ( c1 INT, c2 INT, c3 CHAR(1), PRIMARY KEY(c1), KEY idx_c2 (c2) ); 　　覆盖索引 　　　　如果 where 条件的列和 select 的列都在一个索引中，通过这个索引就可以完成查询，这就叫就叫覆盖索引；当然，覆盖索引基本针对的是组合索引（InnoDB 的聚簇索引有点特殊，具体可以看下面的图） 　　　　针对上面的 tbl_index， select c2 from tbl_index where c2 = 4 ; 是覆盖索引查询，但是这条 SQL 没有意义，如果我们在 tbl_index 表上增加索引 index idx_c2_c3 (c2,c3) ，那么 select c3 from tbl_index where c2 = 4 ; 走覆盖索引查询还是很有意义的，那问题又来了，覆盖索引的意义何在 ？ 我们往下看 　　回表 　　　

摘要 本文以MySQL数据库为研究对象，讨论与数据库索引相关的一些话题。特别需要说明的是，MySQL支持诸多存储引擎，而各种存储引擎对索引的支持也各不相同，因此MySQL数据库支持多种索引类型，如BTree索引，哈希索引，全文索引等等。为了避免混乱，本文将只关注于BTree索引，因为这是平常使用MySQL时主要打交道的索引，至于哈希索引和全文索引本文暂不讨论。 文章主要内容分为三个部分。 第一部分主要从数据结构及算法理论层面讨论MySQL数据库索引的数理基础。 第二部分结合MySQL数据库中MyISAM和InnoDB数据存储引擎中索引的架构实现讨论聚集索引、非聚集索引及覆盖索引等话题。 第三部分根据上面的理论基础，讨论MySQL中高性能使用索引的策略。 摘要 数据结构及算法基础 索引的本质 B-Tree和B+Tree 为什么使用B-Tree（B+Tree） MySQL索引实现 MyISAM索引实现 InnoDB索引实现 索引使用策略及优化 示例数据库 最左前缀原理与相关优化 索引选择性与前缀索引 InnoDB的主键选择与插入优化 后记 参考文献 数据结构及算法基础 索引的本质 MySQL官方对索引的定义为： 索引（Index）是帮助MySQL高效获取数据的数据结构。 提取句子主干，就可以得到索引的本质：索引是数据结构。 我们知道，数据库查询是数据库的最主要功能之一