写一下我对数据库优化的理解,欢迎大家补充
1,sql层面:加索引(注意索引失效场景),索引覆盖(减少一次回表)where后面的条件不在索引上会加表锁
2,表层面:遵守三大范式,尽量不用外键,使用中间表,建表时选择合适的字段(比如如果性别用0,1表示char就会比varchar好)字段要求唯一时建唯一索引比业务中判断是否唯一好(可以了解一下唯一索引和主键索引的区别)
3,数据库层面,如果很少使用范围查询,可以考虑将RR隔离级别换为RC隔离级别(如果你回答了这条,一定要去了解一下RR隔离级别下的间隙锁之类的,防止面试官深问回答不出来)
4,业务层面,redis缓存一些热点数据,用业务去解决一些并发问题,我曾经遇到过一个问题,小程序远程去开一个井(硬件),因为回来消息比较慢,中间其他用户再去开井会出问题。我的解决方案:当一个用户开完井后,将井的sn编号存到redis中并设置一个过期时间,其他用户开井时要去reids中查找是否有这个sn编号,有则无法开。
2,表层面:遵守三大范式,尽量不用外键,使用中间表,建表时选择合适的字段(比如如果性别用0,1表示char就会比varchar好)字段要求唯一时建唯一索引比业务中判断是否唯一好(可以了解一下唯一索引和主键索引的区别)
3,数据库层面,如果很少使用范围查询,可以考虑将RR隔离级别换为RC隔离级别(如果你回答了这条,一定要去了解一下RR隔离级别下的间隙锁之类的,防止面试官深问回答不出来)
4,业务层面,redis缓存一些热点数据,用业务去解决一些并发问题,我曾经遇到过一个问题,小程序远程去开一个井(硬件),因为回来消息比较慢,中间其他用户再去开井会出问题。我的解决方案:当一个用户开完井后,将井的sn编号存到redis中并设置一个过期时间,其他用户开井时要去reids中查找是否有这个sn编号,有则无法开。
全部评论
chatgpt对每个方面的补充和说明:
1. SQL层面:
加索引可以提高查询效率,但需要注意的是,索引不是万能的,不适当的索引会带来额外的性能开销和存储空间占用。在选择索引时需要考虑查询条件的选择性和频率、表的大小、数据的变化等因素,并进行测试和优化。
索引失效的场景有很多,比如使用函数、类型不匹配、数据类型转换等,需要了解各种场景并避免使用或优化查询语句。
索引覆盖可以减少一次回表,即通过覆盖索引就能够得到需要的结果,而无需再访问数据行。这可以通过选择合适的索引、使用SELECT子句限制查询字段等方式来实现。
2. 表层面:
遵守三大范式可以确保数据的完整性和一致性,减少数据冗余和错误,提高数据质量。不过在实际应用中,也需要根据业务需求和数据特点进行权衡和优化。
尽量不用外键可以提高插入和更新的效率,但也可能影响查询的效率和数据完整性。使用中间表可以减少冗余和复杂性,但也可能增加查询和维护的难度和开销。
3. 数据库层面:
将RR隔离级别换为RC隔离级别可以提高并发性能,因为RC隔离级别比RR隔离级别更容易产生幻读和不可重复读,但也需要注意控制事务的粒度和时效性,避免脏读和数据错误。
4. 业务层面:
Redis缓存可以提高读取速度和减轻数据库的负载,但也需要考虑缓存的一致性和更新策略。使用业务解决并发问题可以避免锁和等待的开销和影响,但也需要考虑业务的复杂性和可维护性。在面对具体业务场景时,需要进行具体分析和优化。
其他方面优化数据库查询操作:
1. 避免使用 SELECT *,只查询需要的列。这可以减少数据传输量和提高查询效率。
2. 避免在 WHERE 子句中对列进行运算或函数操作。这会导致索引失效,进而影响查询性能。
3. 避免使用 OR 操作符,尽可能使用 UNION 操作符替代。
4. 使用 EXISTS 或者 IN 子查询替代多表联接操作。
5. 尽量避免在查询中使用 LIKE 操作符,如果必须使用,可以考虑使用全文索引。
6. 避免在 WHERE 子句中对索引列进行类型转换,这会导致索引失效。
7. 对于大批量插入数据,可以考虑使用 LOAD DATA INFILE 或者 INSERT INTO ... VALUES (...) 多行插入,而非单行插入。
8. 对于需要排序的查询结果,使用 ORDER BY 子句时尽量使用索引列进行排序。
9. 对于查询结果不太稳定的情况,可以使用 MySQL 的查询缓存,缓存查询结果,提高查询效率。
10. 使用 EXPLAIN 命令分析 SQL 查询语句的执行计划,找出查询中的性能瓶颈,进行优化。
相关推荐
12-10 19:11
重庆大学 Java 香梨想要offer:一样啊朋友,我也是被驳回了,真的挺让人无语的,为什么不一开始就挂了算了,内耗我这么多天。如果华为给每个人造成的内耗能汇聚起来,该是多大一股能量
点赞 评论 收藏
分享