正常MySQL底层存储索引默认使用的是B+树,但是如果设立了分区表的情况下,他的底层是如何进行存储的呢?
创新互联长期为1000+客户提供的网站建设服务，团队从业经验10年，关注不同地域、不同群体，并针对不同对象提供差异化的产品和服务；打造开放共赢平台，与合作伙伴共同营造健康的互联网生态环境。为曲麻莱企业提供专业的成都网站制作、成都网站建设，曲麻莱网站改版等技术服务。拥有十年丰富建站经验和众多成功案例,为您定制开发。
查看MySQL对应的自己电脑上面的安装目录下,是有一个ibd文件,用innblock和bcview两个小工具，(github上可以搜到),便可以实现对ibd文件的查看,通过对比着没有设立分区的表的ibd文件,就可以看出来
分区表会将索引分成分区个个数的索引树来存储索引，也就是分开存储。
兄弟，primary key是主键，每个表只能有一个主键，而且数据是唯一的。\x0d\x0a可以这样写：\x0d\x0aCREATE TABLE IF NOT EXISTS `".$ctb_name."` (\x0d\x0a `id` INT(9) NOT NULL AUTO_INCREMENT PRIMARY KEY,\x0d\x0a `keyid` VARCHAR(20) NOT NULL,\x0d\x0a `key` VARCHAR(20) NOT NULL,\x0d\x0a `stauts` BOOL NOT NULL DEFAULT'0'，\x0d\x0aindex `idx_status`(`status`)\x0d\x0a )ENGINE = MYISAM DEFAULT CHARSET=utf8;\x0d\x0a不过，status是bool类型的字段，只有true和false，区分度太低，没有必要加索引。\x0d\x0a\x0d\x0a索引目的是为了使查询更快，区分度小的时候不如全表扫描。
mysql创建lower索引的方法：
1、自动创建。在表中定义一个primarykey或者unique时，MySQL数据库会自动创建一个对应的主键索引或者是唯一索引。
2、手动创建。在创建表的时候创建索引，即可给已经有的表创建索引。
Mysql多表联合索引:
1、多表联合索引在查询语句中能加速查询速度。select * from table1,table2 where table1.id = table2.id。
2、多表联合的索引的sql语法，一个user表有4个字段 id name age sex，分别给name age sex建立三个单独的索引，此时建立create index name_age_sex on user(name,age,sex)这个新建立的索引跟前面那三个是独立的。就是说又新建立了空间存储这个新索引。
3、索引的维护主要包括定期清理数据碎片。
上一篇给小伙伴们讲了关于SQL查询性能优化的相关技巧，一个好的查询SQL离不开合理的索引设计。这篇小二就来唠一唠怎么合理的设计一个索引来优化我们的查询速度，要是有不合理的地方...嗯..
当然啦，开个玩笑，欢迎小伙伴们指正！
通常情况下，字段类型的选择是需要根据业务来判断的，通常需要遵循以下几点。
下列各种类型表格内容来自菜鸟教程，权当备忘。
优化建议：
注意： INT(2)设置的为显示宽度，而不是整数的长度，需要配合 ZEROFILL 使用 。
例如 id 设置为 TINYINT(2) UNSIGNED ，表示无符号，可以存储的最大数值为255，其中 TINYINT(2) 没有配合 ZEROFILL 实际没有任何意义，例如插入数字200，长度虽然超过了两位，但是这个时候是可以插入成功的，查询结果同样为200；插入数字5时，同样查询结果为5。
而 TINYINT(2) 配合 ZEROFILL 后，当插入数字5时，实际存储的还是5，不过在查询是MySQL会在前面补上一个0，即查询出来的实际为 05 。
优化建议：
优化建议：
通常来说，考虑好表中每个字段应该使用什么类型和长度，建完表需要做的事情不是马上建立索引，而是先把相关主体业务开发完毕，然后把涉及该表的SQL都拿出来分析之后再建立索引。
尽量少建立单值索引( 唯一索引除外 )，应当设计一个或者两三个联合索引，让每一个联合索引都尽量去包含SQL语句中的 where、order by、group by 的字段，同时确保联合索引的字段顺序尽量满足SQL查询的最左前缀原则。
索引基数是指这个字段在表里总共有多少个不同的值，比如一张表总共100万行记录，其中有个性别字段，性别一共有三个值：男、女、保密，那么该字段的基数就是3。
如果对这种小基数字段建立索引的话，因为索引树中只有男、女、保密三个值，根本没法进行快速的二分查找，同时还需要回表查询，还不如全表扫描嘞。
一般建立索引，尽量使用那些基数比较大的字段，那么才能发挥出B+树快速二分查找的优势来。
在 where 和 order by 出现索引设计冲突时，是优先针对where去设计索引？还是优先针对order by设计索引？
通常情况下都是优先针对 where 来设计索引，因为通常情况下都是先 where 条件使用索引快速筛选出来符合条件的数据，然后对进行筛选出来的数据进行排序和分组，而 where 条件快速筛选出来的的数据往往不会很多。
对生产实际运行过程中，或者测试环境大数据量测试过程中发现的慢查询SQL进行特定的索引优化、代码优化等策略。
终于轮到实战了，小二最喜欢实战了。
写到这里不得不吐槽一下，这个金三银四的跳槽季节，年前提离职了，结果离职还没办完就封村整整两个礼拜了，呜呜呜...
上节小二就提到会有个很有意思的小案例，那么在疫情当下，门都出不去的日子，感觉这个例子更有意思了，咱们来讨论一下各种社交平台怎么做的用户信息搜索呢。
社交平台有一个小伙伴们都喜欢的功能，搜索好友信息，比如小二熟练的点开省份...城市..性别..年龄..身高...
咳咳咳...小二怎么可能干这种事情，小二的心里只有代码，嗯...没错，就是这样。
这个就可以说是对于用户信息的查询筛选了，通常这种表都是非常大数据量的，在不考虑分库分表的情况下，怎么通过索引配合SQL来优化呢？
通常我们在编写SQL是会写出类似如下的SQL来执行，有 where、order by、limit 等条件来查询。
那么接下来小二一个一个慢慢增加字段来分析分析，怎么根据业务场景来设计索引。
针对这种情况，很简单，设计一个联合索引 (provice, city, sex) 就完事了。
那么这时候有小伙伴就会说了，很简单啊，范围字段放最后咱还是知道的，联合索引改成 (provice, city, sex, age) 不就可以了。
嗯，是的，这么干没毛病，但是小伙伴们有没有想过有些人万一既喜欢帅哥又喜欢美女，别想歪了哈...，挺多小姐姐就既喜欢帅哥又喜欢美女的。
那么这个时候小姐姐就不搜索性别了，那么这个时候联合索引只能用到前两个字段了，那么不符合咱们的专业标准啊，咋办呢？这时候还是有办法的，咱们只需要动动小脑袋改改SQL就行了，在没有选择性别时判断一下，改成下面这样就可以了。
咋办嘞，同样往联合索引里面塞，例如 (provice, city, sex, hobby, xx, age) 。
针对这种多个范围查询的话，为了比较好的利用索引，在业务允许的情况下可以使用固定范围，然后数据库字段存储范围标识就可以了，这样就转化为了等值匹配，就可以很好地利用索引了。
例如最后登录时间字段不记录最后登录时间，而是记录设置字段 is_login_within_seven_days 在7天内有登录则为1，否则为0，最后索引设计成 (provice, city, sex, hobby, xx, is_login_within_seven_days, age) 。
那么根据场景最后设计出来的这个索引可能已经可以覆盖大部分的查询流量了，那么如果还有其他一部分热度比较高的查询怎么办呢，办法也很简单啊，再加一两个索引即可。
例如通常会查询这个城市比较受欢迎(评分：score)的小姐姐，这时候添加一个联合索引 (provice, city, sex, score) 那么就可以了。
可以看出，索引时必须结合场景来设计的，思路就是尽量用不超过3个复杂的联合索引来抗住大部分的80%以上的常用查询流量，然后再用一两个二级索引来抗下一些非常用查询流量。
以上就是小二要给大家分享的索引设计，如果能动动你发财的小手给小二点个免费的赞就更好啦~
下篇小二就来讲讲MySQL事务和锁机制。
