业务场景:大批量更新时,数据库长时间CPU占用超过90,影响其他正常业务流程,参考阿里云上的一篇文章:https://help.aliyun.com/knowledge_detail/43562.html 在数据库运维当中,一个DBA比较常遇到又比较紧急的问题,就是突发的CPU满(CPU利用率达到100%),导致业务停滞.遇到CPU满,往往需要从后端数据库开始排查,追溯到具体SQL,最终定位到业务层.下面是这个问题具体的处理方法. 查看连接数变化 CPU利用率到达100%,首先怀疑,是不是业务高

postgresql 配置文件优化 配置文件 默认的配置配置文件是保存在/etc/postgresql/VERSION/main目录下的postgresql.conf文件 如果想查看参数修改是否生效,可以用psql连接到数据库后,用<show 选项名> 来查看.如果要修改shared_buffers, 在ubuntu下可能需要执行命令<sysctl -w>Managing Kernel Resources 主要选项 选项 默认值 说明 是否优化 原因max_connections

使用 gin() 创建全文索引后,虽然有走索引,但是当结果集很大时,查询效率还是很底下, SELECT keyword,avg_mon_search,competition,impressions,ctr,position,suggest_bid,click,update_time FROM keyword WHERE update_time is not null and plainto_tsquery('driver') @@ keyword_participle ORDER BY avg_

硬件和系统配置 操作系统 Ubuntu13.04 系统位数 64 CPU Intel(R) Core(TM)2 Duo CPU 内存 4G 硬盘 Seagate ST2000DM001-1CH164 测试工具 PostgreSQL-9.1.11 测试工具 工具名称 pgbench 数据量 200W(整个数据库大小约为300M) 模拟客户端数 4 线程数 4 测试时间 60秒 准备命令:pgbench -i -s 20 pgbenchdb 测试命令:pgbench -r -j4 -c4 -T60

http://mysql.taobao.org/monthly/2016/06/10/ 在5.7版本中,InnoDB实现了新的handler的records接口函数,当你需要表上的精确记录个数时,会直接调用该函数进行计算. 使用 实际上records接口函数是在优化阶段调用的,在满足一定条件时,直接去计算行级计数.其explain出来的结果相比老版本也有所不同,这里我们使用sysbench的sbtest表来进行测试,共200万行数据. mysql> show create table sbtes

由于是开发阶段,所以并没有配置postgres的参数,都是使用安装时的默认配置,以前运行也不见得有什么不正常,可是前几天我的cpu资源占用突然升高.查看进程,发现有一个postgres的进程占用CPU都是80%以上,而且居高不下: 刚开始以为是配置上需要修改,但事实上,默认配置基本上是很优化的,而且是开发阶段,数据量也并不大.后来通过分析,得出结论,解决问题应该从以下几个方面来逐一考虑: 1,SQL查询方面检查数据检索的索引是否建立,凡是需要查找的字段尽量建立索引,甚至是联合索引:创建索引,包括

对于索引优化真的是门课题,先来研究下最平常的问题,innodb引擎下 怎么让count(*)快一点. 首先需要清楚 innodb 默认是对主键建立聚簇索引,如果没有主键,那就是对具有唯一且非空值的索引来代替,如果也没有,innodb内部就会自己维护一个这样的索引. 聚簇索引存的是索引+数据,二级索引存的是对主键即聚簇索引的指向. 所以通过上面的猜想 1.表中聚簇索引如果有varchar,text的字段,如果存储数据比较多,聚簇索引就会非常的大,就会照成大量数据页分裂.(这里数据页是什么,我也理解

原sql: SELECT res_id_ori FROM wk_sheet A, wk_page b WHERE A .wk_sheet_id = b.wk_sheet_id ') ; 原sql执行计划: Planning time: 0.145 ms Execution time: 1313.189 ms 优化方案:创建联合索引 create index idx_residori_sheetid on wk_page(res_id_ori,wk_sheet_id); sql执行计划: EXPL

在我们平时写SQL时,如果遇到需要排除某些数据时,往往使用id <> xxx and id <> xxx,进而改进为id not in (xxx, xxx); 这样写没有问题,而且简化了SQL,但是往往有些极端情况,使用not in就会造成极大的性能损耗,例如: select * from test where id not in (select id from test_back) and info like '%test%'; 这样的话select id from test_b

几种获取记录数的方法 count(*): MySQL 优化过,扫描的行数小于总记录数.执行效率高. count(1): 遍历所有记录,不取值,对每行尝试添加一个 "1" 列,如果不为 null,就计入累加(引擎层). count(主键): 遍历所有记录,并把每个记录的 id 取出返回 Server 层判断,将不为 null 的计入累加. count(字段): 遍历所有记录,并把每个记录的字段值取出返回 Server 层判断,将不为 null 的计入累加. 效率排序: count(*)

一.什么是扩展统计 扩展统计对象, 追踪指定表.外部表或物化视图的数据. 目前支持的种类: 启用n-distinct统计的 ndistinct. 启用功能依赖性统计的dependencies. 启用最常见的值列表的mcv. 本文仅讨论n-distinct统计信息,在优化器中的作用.手工修改统计信息,使得执行计划发生改变. 二.数据准备 建立一个大表,这个表模拟商业交易明细记录.这个表,不仅有海量的数据,也具有大量的维度信息. create table t_order as select id,

1.select count(*) from table_name 比select count(主键列) from table_name和select count(1) from table_name 要快一些 但是对于千万级来说这还是很慢 2.非聚集索引比聚集索引要快 假如表里只有一个聚集索引,你在建立一个非聚集索引,然后查询时指定使用该非聚集索引,速度将会得到提高 如果聚集索引需要1800毫秒的话 用非聚集索引会降到1300毫秒 select count(*) from tj_ClientA

min/max优化 在表中,一般都是经过优化的. 如下地区表 id area pid 1 中国 0 2 北京 1 ... 3115 3113 我们查min(id), id是主键,查Min(id)非常快. 但是,pid上没有索引, 现在要求查询3113地区的min(id); select min(id) from it_area where pid=69; 试想 id是有顺序的,(默认索引是升续排列), 因此,如果我们沿着id的索引方向走, 那么  第1个 pid=69的索引结点,他的id就正好是

一.前言 这个问题是今天朋友提出来的,关于查询一个1200w的数据表的总行数,用count(*)的速度一直提不上去.找了很多优化方案,最后另辟蹊径,选择了用explain来获取总行数. 二.关于count的优化 网上关于count()优化的有很多.博主这边的思路就是没索引的就建立索引关系,然后使用count(1)或者count(*)来提升速度.这两个函数默认使用的是数据表中最短的那个索引字段.我朋友这边因为表中只有一个索引字段,所以使用count(1)和count(*)没什么区别. MySQL中

基于CentOS7数据库性能优化(Postgresql) 1.  磁盘 a)         Barriers IO i.              通过查看linux是否加载libata,确定是否开启(一般操作系统都是默认开启) [root@localhost ~]# dmesg |grep libata [    2.063756] libata version 3.00 loaded. b)         禁止atime,读文件时不再更新atime,修改/etc/fstab 对应的磁盘,

简介 PostgreSQL 的开发源自上世纪80年代,它最初是 Michael Stonebraker 等人在美国国防部支持下创建的POSTGRE项目.上世纪末,Andrew Yu 等人在它上面搭建了第一个SQL Parser,这个版本称为Postgre95,也是加州大学伯克利分校版本的PostgreSQL的基石[1]. 我们今天看到的 PostgreSQL 的优化器代码主要是 Tom Lane 在过去的20年间贡献的,令人惊讶的是这20年的改动都是持续一以贯之的,Tom Lane 本人也无愧于

1 背景 研究mybatis-plus(以下简称MBP),使用其分页功能时.发现了一个JsqlParserCountOptimize的分页优化处理类,官方对其未做详细介绍,网上也未找到分析该类逻辑的只言片语,这情况咱也不敢用呀,索性深度剖析一下,也方便他人. 2 原理 首先PaginationInterceptor分页拦截器的原理这里不累述(mybatis通用分页封装的实现原理挺简单的,也就那么回事),最终落实到查询上基本是分为2个sql:查count总记录数 + 查真实分页记录.而此类是用优化

注:在执行SQL语句前加上explain可以查看MySQL的执行计划 数据库:MySQL官方提供的sakila数据库 Max优化: 例如:查询最后支付时间 explain select max(payment_date) from payment \G; 询的类型为simple,没有用到任何索引,扫描行数为1万多行,用时0.02sec 优化方法: 在payment_date列建立索引 create index idx_paydate on payment(payment_date); 此执行结果

* { color: #3e3e3e } body { font-family: "Helvetica Neue", Helvetica, "Hiragino Sans GB", "Microsoft YaHei", Arial, sans-serif; font-size: 15px } p { line-height: 25.6px; text-align: justify; margin: 23.7px 0 } blockquote { b

code[class*="language-"], pre[class*="language-"] { background-color: #fdfdfd; -webkit-box-sizing: border-box; -moz-box-sizing: border-box; box-sizing: border-box; margin-bottom: 1em; } :not(pre) > code[class*="language-"]

确定应用程序类型 在 Citus 集群上运行高效查询要求数据在机器之间正确分布.这因应用程序类型及其查询模式而异. 大致上有两种应用程序在 Citus 上运行良好.数据建模的第一步是确定哪些应用程序类型更接近您的应用程序. 概览 多租户应用 实时应用 有时 schema 中有几十个或数百个表 表数量少 一次与一个租户(公司/商店)相关的查询 具有聚合的相对简单的分析查询 用于服务 Web 客户端的 OLTP 工作负载 摄取大量几乎不可变的数据 为每个租户分析查询提供服务的 OLAP 工作负载 通