一个索引包含了查询所需的所有列,这样就不要访问表的实际数据页,提高了查询的效率,索引的底层是B+树,理解了这个东西,就明白索引有多强了,但是也要具体情况具体分析,也不能加太多的索引,不要动不动就加索引,而是要看具体的业务,如果具体的业务需要了,具体的业务查询量特别大,那么就加
我举个例子吧
比如图书表,有以下字段:
BookID(图书编号)
Title(图书标题)
Author(作者)
Year(出版年份)
Genre(类型)
如果我们要查询2008年以后的科技类图书,正常是一个一个查,遍历数据表中的所有数据,如果这张表的数据量特别多,而且是经常性的操作,那么就需要用覆盖索引了,以title Year Genre为覆盖索引,来进行快速查询,就解决了这个业务难题
如果这是一个高并发和大数据的的情况下,该如何解决了?
我的想法是在用覆盖索引的基础上,进行分库分表,对服务进行拆分,微服务架构,然后增加硬件(服务器资源),数据库的读写分离,读的话用redis,写的话用消息队列,如果还不行,对redis采用集群的哨兵模式,这是大佬解决高并发的架构雏形!不断学习,不断让自己变得更强大!