数据库优化思路

数据库优化思路有如下几个方面:

1、建立索引

2、分库、分表、分区

3、数据库引擎

mysql比较常用的数据库引擎是:innodb 、myisam
     myisam查询效率比innodb快1-2倍,
     myisam是表级锁,适用于一次插入多次查询的表,或者是读写分离中读库中的表
     innodb是行级锁,适用于频繁更新,插入,读写分离写库中的表

详细可参考:https://www.cnblogs.com/0201zcr/p/5296843.html

4、预处理

实时数据放入缓存中

历史数据,将复杂sql语句执行出来的结果生成视图,查询的时候直接查询视图,速率显著提高。

5、读写分离

6、增加服务器内存、CPU及网络带宽

对于sql语句优化方面,有如下需要注意的地方:

1、对查询进行优化,尽量避免全表扫描,首先考虑在where及order by涉及的列上加索引

2、避免在where子句中对字段进行null值判断,比如select id from where num is null 将会放弃索引进行全表扫描。
解决办法是设置为默认值,比如0。

3、避免在where子句中使用!= 或者<>,否则会放弃索引进行全表扫描

4、避免在where子句中使用or来连接条件,否则会放弃索引进行全表扫描
解决办法使用union all

5、避免在where子句中使用in 或则 not in ,否则会放弃索引进行全表扫描
解决办法使用exists代替in
select num from a where num in (select num from b)
替换为

select num from a exists (select 1 from b where b.num = a.num)

6、避免全模糊查询,比如select id from a where name like ‘%abc%‘,将放弃索引进行全表扫描
解决办法使用右模糊查询,即select id from a where name like ‘abc%‘

7、避免隐式转换,比如varchar类型的字段a = 1 ,如此会放弃索引进行全表扫描

8、避免在where子句=的左边进行函数、算数运算或则其他表达式运算,否则将放弃索引进行全表扫描

9、尽量使用数字型字段,若只包含数字信息的字段尽量不要设计成字符串类型

10、使用varchar代替char

11、不要出现select * from a 或者 select count(*) from b 这种无意义的语句

参考文章:https://blog.csdn.net/zhoupan301415/article/details/78257783

https://blog.csdn.net/jie_liang/article/details/77340905

原文地址:https://www.cnblogs.com/conswin/p/9374629.html

时间: 2024-11-02 05:54:05

数据库优化思路的相关文章

数据库优化思路与方向

一.基础优化 mysql> show status like 'valus' connections //链接参数 uptime //上线时间 slow_queries //慢查询次数 com_select com_insert com_update com_delete 二.优化查询: mysql> explain select * from handb.fruits; +----+-------------+--------+------+---------------+------+--

MySQL5.6.17学习笔记(一)数据库优化思路

欢迎访问:鲁春利的工作笔记,学习是一种信仰,让时间考验坚持的力量. 本文出自 "鲁春利的工作笔记" 博客,请务必保留此出处http://luchunli.blog.51cto.com/2368057/1705491

MySQL 查询语句优化思路

query 语句的优化思路和原则主要提现在以下几个方面:1. 优化更需要优化的Query:2. 定位优化对象的性能瓶颈:3. 明确的优化目标:4. 从 Explain 入手:5. 多使用profile6. 永远用小结果集驱动大的结果集:7. 尽可能在索引中完成排序:8. 只取出自己需要的Columns:9. 仅仅使用最有效的过滤条件:10. 尽可能避免复杂的Join和子查询 关于explain 用法:explain select * from tables1 where 1 ... 先看一下在

关于秒杀的系统架构优化思路

一.问题的提出 秒杀或抢购活动一般会经过 预约,下单,支付 ,扛不住的地方在于下单,一般会带来2个问题: 1.高并发 比较火热的秒杀在线人数都是10w起的,如此之高的在线人数对于网站架构从前到后都是一种考验. 2.超卖 任何商品都会有数量上限,如何避免成功下订单买到商品的人数不超过商品数量的上限,这是每个抢购活动都要面临的难题. 秒杀系统难做的原因:库存只有一份,瞬间大量用户读和写这些数据. 例如小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万 二.架构 常见站点架构如

单机数据库优化的一些实践(mysql)

数据库优化有很多可以讲,按照支撑的数据量来分可以分为两个阶段:单机数据库和分库分表,前者一般可以支撑500W或者10G以内的数据,超过这个值则需要考虑分库分表.另外,一般大企业面试往往会从单机数据库问起,一步一步问到分库分表,中间会穿插很多数据库优化的问题.本文试图描述单机数据库优化的一些实践,数据库基于mysql,如有不合理的地方,欢迎指正. 1.表结构优化 在开始做一个应用的时候,数据库的表结构设计往往会影响应用后期的性能,特别是用户量上来了以后的性能.因此,表结构优化是一个很重要的步骤.

Join的实现原理及优化思路

前言 前面我们已经了解了MySQLQueryOptimizer的工作原理,学习了Query优化的基本原则和思路,理解了索引选择的技巧,这一节我们将围绕Query语句中使用非常频繁,且随时可能存在性能隐患的Join语句,继续我们的Query优化之旅. Join 的实现原理 在寻找Join语句的优化思路之前,我们首先要理解在MySQL中是如何来实现Join的,只要理解了实现原理之后,优化就比较简单了.下面我们先分析一下MySQL中Join的实现原理. 在MySQL中,只有一种Join算法,就是大名鼎

58沈剑:秒杀系统架构优化思路

有个兄弟分享秒杀系统的优化,其观点有些赞同,大部分观点却并不同意,结合自己的经验,谈谈自己的一些看法. 一.为什么难 秒杀系统难做的原因:库存只有一份,所有人会在集中的时间读和写这些数据. 例如小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万. 又例如12306抢票,亦与秒杀类似,瞬时流量更甚. 二.常见架构 流量到了亿级别,常见站点架构如上: 1)浏览器端,最上层,会执行到一些JS代码 2)站点层,这一层会访问后端数据,拼html页面返回给浏览器 3)服务层,向上游屏

Web下的整体测试 --性能测试及优化思路

随着Internet的日益普及,现在基于B/S结构的大型应用越来越多,可如何对这些应用进行测试成为日益迫切的问题.有许多测试人员来信问我B/S的测试如何做,由于工作较繁忙,对大家提出的问题也是头痛医头脚痛医脚,没有对WEB的测试过程做一个整体的概述.希望通过本篇能够让大家了解大型Web应用是如何来进行测试的. B/S下的功能测试比较简单,关键是如何做好性能测试.目前大多数的测试人员认为只要跑一些测试工具证明我的产品是可以达到性能的就ok了,为了证明而去测试是没有任何价值的,关键是要发现产品性能上

【58沈剑架构系列】秒杀系统架构优化思路

一.秒杀业务为什么难做 1)im系统,例如qq或者微博,每个人都读自己的数据(好友列表.群列表.个人信息): 2)微博系统,每个人读你关注的人的数据,一个人读多个人的数据: 3)秒杀系统,库存只有一份,所有人会在集中的时间读和写这些数据,多个人读一个数据. 例如:小米手机每周二的秒杀,可能手机只有1万部,但瞬时进入的流量可能是几百几千万. 又例如:12306抢票,票是有限的,库存一份,瞬时流量非常多,都读相同的库存.读写冲突,锁非常严重,这是秒杀业务难的地方.那我们怎么优化秒杀业务的架构呢? 二