橙子建站有风险吗百度指数pc版
-
对经常查询的区分度高的条件字段建立索引，也就是用在where条件里的字段。使用没有建立索引的非主键字段作为条件查询时，会进行全表扫描，因为这个字段的数据分步是不规律的，但是需要避免在频繁更新的字段上建立索引，因为索引维护成本高。
-
要尽量做到覆盖索引，覆盖索引是指索引包含查询所需的所有字段，查询的字段中尽可能不包含id和where条件以外的字段，如果有的话可以考虑是否可以和where条件中的字段建立联合索引，避免回表查询，因为如果查询的字段不在当前索引中的时候，where条件中会把符合的数据id筛选出来，然后再次通过id去查询相应的字段，导致性能降低。
-
遵循最左前缀法则，避免索引失效。最左前缀指的是例如建立了一个联合索引(A,B,C)，如果where条件中包含A则可以走索引查询，包含A和B也可以走索引，包含A,B,C也可以走索引，但是如果不包含A条件，则索引就会失效，需要注意的是查询条件中字段的顺序不影响最左前缀，只要包含最左字段即可，但在order by和group by中需要保持顺序与索引一致。
-
查询的时候避免全表扫描，通过explain分析查询语句的type列是不是all，是的话代表是全表扫描，看看是不是没有建立索引或者索引失效。
-
避免回表查询，要知道一个表只有一个聚集索引，其他的都是辅助索引，聚集索引一般是主键索引，聚集索引的叶子节点存储行数据，非聚集索引的叶子节点存储主键值。回表即通过非聚集索引查到主键后，再查聚集索引获取完整数据。回表的流程就是，当通过某个辅助索引查询到索引位置时，得到主键id、此时如果发现有name或者title字段这些没在索引中的字段，则需要吧获得的主键id拿回去查一遍聚集索引，这也就是回表查询，会导致性能降低，这也是为什么尽量查询的时候不用用select *的原因。
-
对limit进行优化，当数据量过大的时候，如果取第2000000万条数据的后面10条数据，也就是2000000~2000009的数据，此时如果直接【select * from table limit 2000000, 10;】的话，想当于你查询了两百万条的数据。因为在查询的时候数据库会对数据进行排序，然后拿出第2000000万条后的10条数据给你。但是我们通过主键查询的话，就可以直接获取到聚集索引上的数据，性能可以提高很多，可以考虑先获取到第2000000万条后的10条数据的id。但是where条件里面是不能有包含limit的子查询的，所以可以考虑通过join的方式进行联表查询获取数据，还可以进行游标分页，如【select * from table where id > 2000000 order by id limit 10;】。
-
插入数据的id，如果不是自增id，需要考虑尽量顺序插入，如果随机插入的话会导致页分裂，页分裂会导致产生磁盘碎片和写入性能下降。另外，自增主键适用于单机场景，分布式场景可使用雪花算法或 UUID v7（时间有序）。
-
对order by和group by的字段进行优化，建立相关的索引，需要注意的是创建索引的时候，默认是升序排列的，此时如果order by的字段是降序则会倒序排列，性能不差，但是如果排序字段是一升一降，导致索引的排序没法生效，此时可以考虑创建order by的字段相关索引。另外，order by和group by也是需要满足最左前缀法则的，区别在于where条件中只要包含最左字段即可，顺序并不固定，order by和group by 则是要求顺序也一致。
-
对长文本字段进行查询，可以考虑建立前缀索引，提高查询效率，使用公式select count(distinct substring(column, 1, 10)) / count(*)进行分析，查看合适的前缀数量，太少了匹配度很低，太长了索引空间又太大，上述公式的值小于等于1，代表的含义就是字段里面通过前10个字符来建立索引的话，有相应的概率找到某一条数据。如果是1，也就是100%，此时通过前缀可以锁定某一条数据，如果是0.9，那么代表数据里面有部分数据的前缀是相同的，但是此时可能只需要通过前4-5个字符建立索引，节省了索引空间。前缀索引的缺点就是无法覆盖排序和范围查询。
-
批量插入数据，在需要插入很多数据的时候，避免一条条地重复插入，而是考虑批量插入，降低事务的开销。在数据达到百万级的时候可以考虑通过文件的方式导入数据，比如MySQL就提供了专门导出数据的工具mysqldump和导入命令load data local infile。
-
高并发场景下考虑通过主从复制的机制实现读写分离。