BTree

为了项目的稳定，代码的高效，管理的便捷，在开发团队内部会制定各种各样的规范 这里分享一份我们定义的MySQL开发规范，欢迎交流拍砖 数据库对象命名规范 数据库对象 命名规范的对象是指数据库SCHEMA、表TABLE、索引INDEX、约束CONSTRAINTS等的命名约定 数据库对象命名原则 命名使用具有意义的英文词汇，词汇中间以下划线分隔 命名只能使用英文字母、数字、下划线 避免用MySQL的保留字如：call、group等 所有数据库对象使用小写字母 数据库命名规范 数据库名不能超过30个字符 数据库命名必须为项目英文名称或有意义的简写 数据库创建时必须添加默认字符集和校对规则子句。默认字符集为UTF8(已迁移dumbo的使用utf8mb4) 命名应使用小写 表命名规范 同一个模块的表尽可能使用相同的前缀，表名称尽可能表达含义 多个单词以下划线（_）分隔 表名不能超过30个字符 普通表名以t_开头，表示为table，命名规则为t_模块名（或有意义的简写）_+table_name 临时表(运营、开发或数据库人员临时用作临时进行数据采集用的中间表)命名规则：加上tmp前缀和8位时间后缀（tmp_test_user_20181109） 备份表（DBA备份用作保存历史数据的中间表）命名规则：加上bak前缀和8位时间后缀（bak_test_user_20181109） 命名应使用小写

1：数据库表 -- ---------------------------- -- Table structure for t_user -- ---------------------------- DROP TABLE IF EXISTS `t_user`; CREATE TABLE `t_user` ( `t_user_id` bigint ( 255 ) NOT NULL AUTO_INCREMENT, `t_user_name` varchar ( 255 ) CHARACTER SET utf8mb4 COLLATE utf8mb4_bin NULL DEFAULT NULL , `t_user_age` smallint ( 255 ) NULL DEFAULT NULL , PRIMARY KEY (`t_user_id`) USING BTREE ) ENGINE = InnoDB AUTO_INCREMENT = 3 CHARACTER SET = utf8mb4 COLLATE = utf8mb4_bin ROW_FORMAT = Dynamic; -- ---------------------------- -- Table structure for t_user_address -- ---------------------------- DROP

CDA数据分析师 出品 大家好，欢迎来到小编的MySQL课堂。今天我们一起来看一下MySQL中的索引、关联子查询以及语句的优化技巧。 一、MySQL的索引 数据库索引，是数据库管理系统中一个排序的数据结构，以协助快速查询数据库表中数据。 1、索引的意义 索引用于快速找出在某个字段中有特定值的行。如果不使用索引，MySQL必须从第一条记录开始检索表中的每一条记录，直到找出相关的行，那么表越大，查询数据所花费的时间就越多。如果在表中查询的字段有索引，MySQL能够快速到达一个位置去检索数据文件，而不需要再去查看所有数据，那么将会节省很大一部分查询时间。比如说emp表中1W个员工的记录，要查询salesman的员工信息，如果没有索引，服务器会从表中第一条记录开始，一条条往下遍历，直到找到职位为salesman的员工信息。如果有了索引，它会把job这个字段，通过一定的方法进行存储，在查询这个字段上的信息时，能够快速找到对应的数据，而不需要再遍历1W条记录了。 2、索引的优缺点 所有MySQL的字段类型都可以添加索引，但是索引也不是越多越好，而是要根据业务数据合理的使用。 优点 · 通过索引对数据进行检索，大大提高了数据的查询效率。 缺点 · 创建索引和维护索引要耗费时间，并且随着数据量的增加所耗费的时间也会增加。 · 索引也需要占空间的，创建的索引太多，索引文件也会占用数据库的存储空间。

【推荐阅读】微服务还能火多久？>>> 什么叫做覆盖索引？ 在了解覆盖索引之前我们先大概了解一下什么是聚集索引(主键索引)和辅助索引(二级索引) 聚集索引（主键索引）： 聚集索引就是按照每张表的主键构造一颗B+树，同时叶子节点中存放的即为整张表的记录数据。 聚集索引的叶子节点称为数据页，聚集索引的这个特性决定了索引组织表中的数据也是索引的一部分。 辅助索引（二级索引）： 非主键索引，叶子节点=键值+书签。Innodb存储引擎的书签就是相应行数据的主键索引值。 再来看看什么是覆盖索引，有下面三种理解： 解释一： 就是select的数据列只用从索引中就能够取得，不必从数据表中读取，换句话说查询列要被所使用的索引覆盖。 解释二： 索引是高效找到行的一个方法，当能通过检索索引就可以读取想要的数据，那就不需要再到数据表中读取行了。如果一个索引包含了（或覆盖了）满足查询语句中字段与条件的数据就叫 做覆盖索引。 解释三：是非聚集组合索引的一种形式，它包括在查询里的Select、Join和Where子句用到的所有列（即建立索引的字段正好是覆盖查询语句[select子句]与查询条件[Where子句]中所涉及的字段，也即，索引包含了查询正在查找的所有数据）。 　　不是所有类型的索引都可以成为覆盖索引。覆盖索引必须要存储索引的列，而哈希索引、空间索引和全文索引等都不存储索引列的值，所以MySQL只能使用B

【今日推荐】：为什么一到面试就懵逼！>>> 注意：本文基于MySQL的InnoDB引擎说明。 一、什么是最左前缀原则 对于该表，如果按照name字段来建立索引的话，采用B+树结构，大概的索引如下： 如果要进行模糊查找，查找name 以“张"开头的所有人的ID，即 sql 语句为： select ID from table where name like ' 张% ' 由于在B+树结构的索引中，叶子节点是一个有序的链表，当我们快速定位到 ID 为 100的张一后，可以直接向右遍历所有张开头的人，直到条件不满足为止。这种定位到最左边，然后向右遍历寻找的方式，就是我们所说的 最左前缀原则 。 只是当个索引，在组合索引中更能感受到： 示例：一个(a,b,c)的组合索引。 通过a,b条件查询能不能使用或命中这个索引？-----能 通过b,c条件查询能不能使用或命中这个索引？-----不能 原因：索引文件具有B-Tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。 二、为什么用B+树作索引二不用哈希表作索引 1. 不支持模糊查询：哈希表是把索引字段映射成对应的哈希码然后再存放在对应的位置，这样的话，如果我们要进行模糊查找的话，显然哈希表这种结构是不支持的，只能遍历这个表。而B+树则可以通过最左前缀原则快速找到对应的数据。 2. 不支持范围查询：如果我们要进行范围查找

【今日推荐】：为什么一到面试就懵逼！>>> 以ftdp项目来说，其多个数据表都会对经常被查询的字段添加索引，比如tin_comments表中针对5个字段设计了BTREE索引。 一、对比测试 mysql> SELECT id,FROM_UNIXTIME(time) FROM article WHERE a.ti='标题' 给ti字段添加一个BTREE索引： mysql> ALTER TABLE article ADD INDEX index_article_ti ON ti(200); 二、MySQL索引的概念 索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分)，它们包含着对数据表里所有记录的引用指针。 索引分为聚簇索引和非聚簇索引两种，聚簇索引是按照数据存放的物理位置为顺序的，而非聚簇索引就不一样了；聚簇索引能提高多行检索的速度，而非聚簇索引对于单行的检索很快。 三、索引的类型 1、普通索引 这是最基本的索引，它没有任何限制，比如上文中为title字段创建的索引就是一个普通索引 创建方式： 直接创建索引 CREATE INDEX index_name ON table(column(length)) 修改表结构的方式添加索引 ALTER TABLE table_name ADD INDEX index_name ON (column(length)) 删除索引

作者： jiaxin 出处： http://www.cnblogs.com/YangJiaXin/ 目录 背景 分析测试 select xxx_record语句 delete xxx_record语句 实施 索引优化后 delete大表优化为小批量删除 总结 背景 XX实例（一主一从）xxx告警中每天凌晨在报SLA报警，该报警的意思是存在一定的主从延迟（若在此时发生主从切换，需要长时间才可以完成切换，要追延迟来保证主从数据的一致性） XX实例的慢查询数量最多（执行时间超过1s的sql会被记录），XX应用那方每天晚上在做删除一个月前数据的任务 分析 使用pt-query-digest工具分析最近一周的mysql-slow.log pt-query-digest --since=148h mysql-slow.log | less 结果第一部分 最近一个星期内，总共记录的慢查询执行花费时间为25403s，最大的慢sql执行时间为266s，平均每个慢sql执行时间5s，平均扫描的行数为1766万 结果第二部分 select arrival_record操作记录的慢查询数量最多有4万多次，平均响应时间为4s，delete arrival_record记录了6次，平均响应时间258s select xxx_record语句 select arrival_record

文章目录 1.为什么要建立索引？ 2.索引的分类有哪些？ 2.1 _id索引 2.2 单字段索引 （Single Field Index） 2.2 多键索引（Multikey Index） 2.3 复合索引 (Compound Index) 2.4 文本索引（Text Index） 2.5 哈希索引（Hashed Index） 2.6 地理位置索引（Geospatial Index） 2.7 其它索引 3.索引优化 3.1 db profiler 3.2 查询计划 4. 索引管理 4.1 建立索引 4.2 查询集合索引 4.3 删除集合索引 4.4 索引重建 1.为什么要建立索引？ 假设MongoDB person集合里包含插入了4个文档，其存储后位置信息如下(为方便描述，文档省去_id字段) 位置信息 文档 pos1 {“name” : “jack”, “age” : 19 } pos2 {“name” : “rose”, “age” : 20 } pos3 {“name” : “jack”, “age” : 18 } pos4 {“name” : “tony”, “age” : 21} pos5 {“name” : “adam”, “age” : 18} 假设现在有个查询 db.person.find( {age: 18} ), 查询所有年龄为18岁的人，这时需要遍历所有的文档

背景 多数的移动端APP都会有做任务领取奖励的功能模块，这类需求的目的是培养用户使用习惯，提升用户活跃性，用户完成任务获得积分奖励，通过积分兑换商品或者充值话费，微信体现等。 拟定需求场景(如图↓)，概要：APP底部导航中新增小任务Tab，点击Tab可查看任务完成进度和领取情况，点击去完成跳转到做任务的业务界面，当用户完成任务并且满足领取条件的时候，任务Tab需要红点提醒用户当前有奖励可领取，用户领取后并且当前没有待领取奖励小红点消失，任务完成进度和领取状态仅保持当天，隔天刷新。 业务分析 在开发前需要对需求进行整理，对细节进行确认，然后设计解决方案，预估开发时间，这里将对于业务中核心的内容进行梳理： 用户想要完成任务，需要去操作其他业务功能，如：评论成功后需要完成每日评论任务，关注主题后完成关注新手任务，这里就涉及核心问题， 任务需要依赖于其他业务 为了保障后续拓展性， 任务需要支持后台管理 ，配置任务名，描述，任务类型（每日，新手，活动），完成次数，奖励积分数量，去完成跳转uri 等 用户完成任务后不用自动领取奖励，需要进入到任务列表点击领取操作，可领取时导航Tab需要小红点提醒，和产品确认任务的完成和提醒的用户体验 可以接受短时间延迟 用户多次操作业务，或者出现重复操作（恶意并发请求刷积分），保证任务只能完成一次并且只能领取一次奖励， 需要保证幂等性 方案设计 核心目标：

背景 多数的移动端APP都会有做任务领取奖励的功能模块，这类需求的目的是培养用户使用习惯，提升用户活跃性，用户完成任务获得积分奖励，通过积分兑换商品或者充值话费，微信体现等。 拟定需求场景(如图↓)，概要：APP底部导航中新增小任务Tab，点击Tab可查看任务完成进度和领取情况，点击去完成跳转到做任务的业务界面，当用户完成任务并且满足领取条件的时候，任务Tab需要红点提醒用户当前有奖励可领取，用户领取后并且当前没有待领取奖励小红点消失，任务完成进度和领取状态仅保持当天，隔天刷新。 业务分析 在开发前需要对需求进行整理，对细节进行确认，然后设计解决方案，预估开发时间，这里将对于业务中核心的内容进行梳理： 用户想要完成任务，需要去操作其他业务功能，如：评论成功后需要完成每日评论任务，关注主题后完成关注新手任务，这里就涉及核心问题， 任务需要依赖于其他业务 为了保障后续拓展性， 任务需要支持后台管理 ，配置任务名，描述，任务类型（每日，新手，活动），完成次数，奖励积分数量，去完成跳转uri 等 用户完成任务后不用自动领取奖励，需要进入到任务列表点击领取操作，可领取时导航Tab需要小红点提醒，和产品确认任务的完成和提醒的用户体验 可以接受短时间延迟 用户多次操作业务，或者出现重复操作（恶意并发请求刷积分），保证任务只能完成一次并且只能领取一次奖励， 需要保证幂等性 方案设计 核心目标：