数据库优化

　　设计好MySql的索引可以让你的数据库飞起来，大大的提高数据库效率。设计MySql索引的时候有一下几点注意： 　　1,创建索引 　　对于查询占主要的应用来说，索引显得尤为重要。很多时候性能问题很简单的就是因为我们忘了添加索引而造成的，或者说没有添加更为有效的索引导致。如果不加索引的话，那么查找任何哪怕只是一条特定的数据都会进行一次全表扫描，如果一张表的数据量很大而符合条件的结果又很少，那么不加索引会引起致命的性能下降。但是也不是什么情况都非得建索引不可，比如性别可能就只有两个值，建索引不仅没什么优势，还会影响到更新速度，这被称为过度索引。 　　2,复合索引 　　比如有一条语句是这样的：select * from users where area='beijing' and age=22; 　　如果我们是在area和age上分别创建单个索引的话，由于mysql查询每次只能使用一个索引，所以虽然这样已经相对不做索引时全表扫描提高了很多效率，但是如果在area、age两列上创建复合索引的话将带来更高的效率。如果我们创建了（area, age, salary）的复合索引，那么其实相当于创建了（area,age,salary）、（area,age）、（area）三个索引，这被称为最佳左前缀特性。因此我们在创建复合索引时应该将最常用作限制条件的列放在最左边，依次递减。 　　3

前言 平时在写一些小web系统时，我们总会对mysql不以为然。然而真正的系统易用应该讲数据量展望拓展到千万级别来考虑。因此，今天下午实在是无聊的慌，自己随手搭建一个千万级的数据库，然后对数据库进行一些简单的CRUD来看看大数据情况下的CRUD效率。 结果发现，曾经简单的操作，在数据量大的时候还是会造成操作效率低下的。因此先写下这篇文章，日后不断更新纪录一下自己工作学习到的Mysql优化技巧。 搭建千万级数据库 首先，需要一个测试环境。一开始想到的是写一个SImple JDBC程序然进行简单的数据INSERT。结果发现单线程情况下，每次INSERT了一百多万条的时候效率就变得非常的低下。但是程序也没报OUT MEMORY之类的异常。初步判断应该是单一线程不断的疯狂创建PrepareStatement对象CG没来得及清理造成内存逐渐被吃紧的原因。 后来改进了一下，用多线程的机制。创建十个进程，每个负责一万条数据的插入。这效率一下子提升了好几倍。然而好景不长，很快的Java程序报错：OUT MEMORY。内存溢出了，CG没来得及清理。 这可把我给急的了。插入的太快内存CPU吃紧，插入的太慢又失去了创建测试环境“快”的初衷。后来想了下，既然是要批量插入数据，那么不是可以简单的写一段数据库存储过程吗？ 于是，先建立一张测试表，就叫goods表吧。先写sql语句创建表： CREATE

本文出自头条号老王谈运维，转载请说明出处。 MySQL 数据库瓶颈对 DBA 程序员而言，是非常棘手的问题。要正确的优化SQL，我们需要快速定位能性的瓶颈点，也就是说快速找到我们SQL主要的开销在哪里？下面小编将从数据库数据库性能优化的目标和方法两方面阐述如何通过性能调优突破 MySQL 数据库性能瓶颈。 优化目标 减少 IO 次数 IO永远是数据库最容易瓶颈的地方，这是由数据库的职责所决定的，大部分数据库操作中超过90%的时间都是 IO 操作所占用的，减少 IO 次数是 SQL 优化中需要第一优先考虑，当然，也是收效最明显的优化手段。 降低 CPU 计算 除了 IO 瓶颈之外，SQL优化中需要考虑的就是 CPU 运算量的优化了。order by, group by,distinct … 都是消耗 CPU 的大户（这些操作基本上都是 CPU 处理内存中的数据比较运算）。当我们的 IO 优化做到一定阶段之后，降低 CPU 计算也就成为了我们 SQL 优化的重要目标。 优化方法 改变 SQL 执行计划 明确了优化目标之后，我们需要确定达到我们目标的方法。对于 SQL 语句来说，达到上述2个目标的方法其实只有一个，那就是改变 SQL 的执行计划，让他尽量“少走弯路”，尽量通过各种“捷径”来找到我们需要的数据，以达到 “减少 IO 次数” 和 “降低 CPU 计算” 的目标 order

出处： https://www.cnblogs.com/easypass/archive/2010/12/ 08/1900127.html 1.数据库访问优化法则 要正确的优化SQL，我们需要快速定位能性的瓶颈点，也就是说快速找到我们SQL主要的开销在哪里？而大多数情况性能最慢的设备会是瓶颈点，如下载时网络速度可能会是瓶颈点，本地复制文件时硬盘可能会是瓶颈点，为什么这些一般的工作我们能快速确认瓶颈点呢，因为我们对这些慢速设备的性能数据有一些基本的认识，如网络带宽是2Mbps，硬盘是每分钟7200转等等。因此，为了快速找到SQL的性能瓶颈点，我们也需要了解我们计算机系统的硬件基本性能指标，下图展示的当前主流计算机性能指标数据。 从图上可以看到基本上每种设备都有两个指标： 延时（响应时间）：表示硬件的突发处理能力； 带宽（吞吐量）：代表硬件持续处理能力。 从上图可以看出，计算机系统硬件性能从高到代依次为： CPU——Cache(L1-L2-L3)——内存——SSD硬盘——网络——硬盘 由于SSD硬盘还处于快速发展阶段，所以本文的内容不涉及SSD相关应用系统。 根据 数据库 知识，我们可以列出每种硬件主要的工作内容： CPU及内存：缓存数据访问、比较、排序、事务检测、SQL解析、函数或逻辑运算； 网络：结果数据传输、SQL请求、远程数据库访问（dblink）； 硬盘：数据访问、数据写入

系统：windows7旗舰版 64位。oracle数据库服务器版本：oracle11g。oracle数据库客户端版本：64位 Version 12.2.0.1.0。PL/SQL版本：【Version 12.0.7.1837（64 bit）】。 一、下载： 1、官网下载： 官网下载速度慢，不推荐，官网网址【https://www.allroundautomations.com】，有兴趣的小伙伴可以去看看。 2、其他下载： 现在网上有许多资源，百度一下，找到合适的版本下载即可，或者到CSDN【网址：https://www.csdn.net】搜PL/SQL Developer有很多上传的资源，小伙伴们可以根据自己的需要下载不同版本。需要安装的根据提示确定安装即可，免安装的解压即可。需要注册码的，这里就不贴了，网上有很多，还是百度一下、哈哈 二、连接数据库： 1、前置条件： 已安装oracle数据库服务器 已安装oracle数据库客户端 2、找到首选项： 通过桌面图标，或者到PL/SQL目录下，找到【plsqldev.exe】鼠标左键双击启动，登录界面点击【Cancel】，先进入主界面： 进入PL/SQL主界面，点击上方的首选项： 3、配置【Oracle Home】和【OCI library】： 【Oracle Home】：即oracle客户端安装的位置 （我的是在D:\apps\dev

** 百万级数据库优化方案 ** 1.对查询进行优化，要尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。 2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num is null 最好不要给数据库留NULL，尽可能的使用 NOT NULL填充数据库. 备注、描述、评论之类的可以设置为 NULL，其他的，最好不要使用NULL。 不要以为 NULL 不需要空间，比如：char(100) 型，在字段建立时，空间就固定了， 不管是否插入值（NULL也包含在内），都是占用 100个字符的空间的，如果是varchar这样的变长字段， null 不占用空间。 可以在num上设置默认值0，确保表中num列没有null值，然后这样查询： select id from t where num = 0 3.应尽量避免在 where 子句中使用 != 或 <> 操作符，否则将引擎放弃使用索引而进行全表扫描。 4.应尽量避免在 where 子句中使用 or 来连接条件，如果一个字段有索引，一个字段没有索引，将导致引擎放弃使用索引而进行全表扫描，如： select id from t where num = 10 or Name = 'admin' 可以这样查询：

COUNT的几种用法 COUNT（expr），返回select语句检索行中expr的值不为NULL的数量，结果是一个BIGINT值 如果没有命中任何记录，返回0 COUNT（*）统计时会包含值为NULL的行数 COUNT（*）的优化 MyISAM：一个简单得优化，它把表的总行数单独记录下来，如果从一张表中使用COUNT（*）进行查询，就可以直接返回这个记录下来的数值就可以了 InnoDB：应为innodb大部分操作是行级锁，所以不能用上面的缓存操作。所以InnoDB进行查询行数时，只是为了统计行数，会在扫表的过程中，选择一个成本较低的索引进行，大大节省空间。Mysql会选择最小的非聚簇索引来扫表。 COUNT（1）和COUNT（*）区别 对与COUNT（1）和COUNT（*）来说，mysql的优化是完全一样的，根本不存在谁比谁快 建议使用COUNT（*），因为这个是sql92中定义的标准统计行数的语法。 COUNT（字段） 查询比较简单粗暴，就是进行全表扫描，判断指定字段是否为NULL，不是NULL则累加。 多了一个判断NULL的操作，所以效率会比COUNT（*）慢 来源： CSDN 作者： white_zzZ 链接： https://blog.csdn.net/white_zzZ/article/details/104106558

前面一篇文章从实例的角度进行数据库优化，通过配置一些参数让数据库性能达到最优。但是一些“不好”的SQL也会导致数据库查询变慢，影响业务流程。本文从SQL角度进行数据库优化，提升SQL运行效率。 判断问题SQL 判断SQL是否有问题时可以通过两个表象进行判断： 系统级别表象 CPU消耗严重 IO等待严重 页面响应时间过长 应用的日志出现超时等错误 可以使用sar命令，top命令查看当前系统状态。 也可以通过Prometheus、Grafana等监控工具观察系统状态。（感兴趣的可以翻看我之前的文章） SQL语句表象 冗长 执行时间过长 从全表扫描获取数据 执行计划中的rows、cost很大 冗长的SQL都好理解，一段SQL太长阅读性肯定会差，而且出现问题的频率肯定会更高。更进一步判断SQL问题就得从执行计划入手，如下所示： 执行计划告诉我们本次查询走了全表扫描Type=ALL，rows很大(9950400)基本可以判断这是一段"有味道"的SQL。 获取问题SQL 不同数据库有不同的获取方法，以下为目前主流数据库的慢查询SQL获取工具 MySQL 慢查询日志 测试工具loadrunner Percona公司的ptquery等工具 Oracle AWR报告 测试工具loadrunner等 相关内部视图如v 、 、 、 session_wait等 GRID CONTROL监控工具 达梦数据库

一、MySQL 会遇到的问题： 　　1、 高并发的读写效率低问题 ---- 解决方案：集群，分布式。 　　2、 海量数据的读写效率低问题 ----- 解决方案：分表，分库。 　　3、 高可用和高扩展 ---- 解决方案：动态扩展服务器、防止单点故障、容灾。 二、关系型数据库优化：（原则： 先单机，后多机。 ） 　　2.1 单机 优化方案 ： 　　　　1.慢SQL的定义--> 分析慢SQL -- 解决慢SQL。 　　　 　　　　2. 表的设计、索引、引擎的优化。 　　3. 分表(垂直分表、水平分表)、分区、分库 的优化。 　　 4. 缓存做集群。 　　　　5.SQL语句优化 　　 　　2.2 多机优化方案 （分为多个数据库）： 　　　　1. 读写分离（要保证 主从同步 ）： 　　　　　　 28 原则：如果有10个数据库，则 2 个专门做增删改的数据库， 8 个专门做查询的数据库。 　　　　2. 缓存做集群 三、定位慢SQL 　 　　3.1 查看数据库状态： 　　　　3.1.1 查看运行时间： show status like ‘uptime’; 　　　　3.1.2 CRUD 执行次数： 　　　　　　Show status like ‘Com_%’; 　　　　　　Show status like ‘Com_update%’ 　　　　　　Show status like ‘Com

数据库的操作越来越成为整个应用的性能瓶颈了，这点对于Web应用尤其明显。关于数据库的性能，这并不只是DBA才需要担心的事，而这更是我 们程序员需要去关注的事情 1.为查询缓存优化你的查询 mysql> show variables like '%query_cache%'; （query_cache_type 为 ON 表示已经开启） +------------------------------+----------+ | Variable_name | Value | +------------------------------+----------+ | have_query_cache | YES | | query_cache_limit | 1048576 | | query_cache_min_res_unit | 4096 | | query_cache_size | 20971520 | | query_cache_type | ON | | query_cache_wlock_invalidate | OFF | +------------------------------+----------+ 如果不是ON，修改配置文件以开启查询缓存： > vi /etc/my.cnf [mysqld]中添加： query_cache_size = 20M #缓存的大小