Percona Server

SQLAdvisor使用(Centos6.8版本)

纵饮孤独 提交于 2020-12-17 02:08:12
SQLAdvisor是由美团点评公司技术工程部DBA团队(北京)开发维护的一个分析SQL给出索引优化建议的工具。它基于MySQL原生态词法解析,结合分析SQL中的where条件、聚合条件、多表Join关系 给出索引优化建议。目前SQLAdvisor在美团点评广泛应用,包括美团支付、酒店旅游、外卖、团购等产品线,公司内部对SQLAdvisor的开发全面转到github上,开源和内部使用保持一致。 主要功能:输出SQL索引优化建议 下载安装包:SQLAdvisor-2.0.tar.gz rpm -q cmake libaio-devel libffi-devel glib2 glib2-devel yum install cmake libaio-devel libffi-devel glib2 glib2-devel #在SQLAdvisor编译时需要这个 rpm -ivh percona-release-0.1-3.noarch.rpm tar -xvf Percona-Server-5.6.29-76.2-rddf26fe-el6-x86_64-bundle.tar rpm -ivh Percona-Server-server-56-5.6.29-rel76.2.el6.x86_64.rpm --nodeps rpm -ivh Percona-Server-client-56-5

SQL优化工具SQLAdvisor使用

↘锁芯ラ 提交于 2020-12-16 13:03:55
一、简介 在数据库运维过程中,优化SQL是业务团队与DBA团队的日常任务。例行SQL优化,不仅可以提升程序性能,还能够降低线上故障的概率。 目前常用的SQL优化方式包括但不限于:业务层优化、SQL逻辑优化、索引优化等。其中索引优化通常通过调整索引或新增索引从而达到SQL优化的目的。索引优化往往可以在短时间内产生非常巨大的效果。如果能够将索引优化转化成工具化、标准化的流程,减少人工介入的工作量,无疑会大大提高DBA的工作效率 SQLAdvisor是由美团点评公司DBA团队(北京)开发维护的SQL优化工具:输入SQL,输出索引优化建议。 它基于MySQL原生词法解析,再结合SQL中的where条件以及字段选择度、聚合条件、多表Join关系等最终输出最优的索引优化建议。目前SQLAdvisor在公司内部大量使用,较为成熟、稳定。 美团点评致力于将SQLAdvisor打造成一款高智能化SQL优化工具,选择将已经在公司内部使用较为成熟的、稳定的SQLAdvisor项目开源,github地址。希望与业内有类似需求的团队,一起打造一款优秀的SQL优化产品。 目前SQLAdvisor在美团点评内部广泛应用,公司内部对SQLAdvisor的开发全面转到github上,开源和内部使用保持一致。 主要功能:输出SQL索引优化建议 GitHup地址:https://github.com/Meituan

mysql客户端报错:libmysqlclient_16 not defined in file libmysqlclient.so.16

江枫思渺然 提交于 2020-05-06 08:44:16
报错情况: 安装完mydumper之后( 上一篇文章 ),登陆Mysql客户端报错:version libmysqlclient_16 not defined in file libmysqlclient.so.16 with link time reference 同样:mysql的其他客户端都出现了同样的问题,比如:mysqladmin,mysqldumper等,但是mydumper却能正常使用! 很明显,这是库文件的连接出了问题,第一想法,是mydumper安装后什么包修改了这个原本正常的链接,上一篇文章(链接在上面)中有关Mysql的包只有mysql-devel,检查一下是不是这个mysql-devel修改了原有的参数 ldd $(which mysql) | grep mysql rpm -qf /usr/lib64/libmysqlclient.so.16 发现这个libmysqlclient.so.16 并没有在任何包中。 我最近使用可能会牵扯mysql的还有一个percona toolkit,会不会是这个原因呢? rpm -qa | grep Percona Percona-Server-shared-51-5.1.73-rel14.12.624.rhel6.x86_64 果然是这个percona-server,安装toolkit时图便宜,使用了yum

数据库原理

微笑、不失礼 提交于 2020-05-04 10:10:35
1、数据库管理系统   1>数据库是数据的汇集,它以一定形式存于存储介质上   2>DBMS是管理数据库的系统软件,它实现数据库系统的各种功能,是数据库系统的核心   3>DBA(数据库管理员)负责数据库的规划、设计、协调、维护、管理和性能优化等工作   4>应用程序指以数据库为基础的应用程序 2、数据库管理系统的优点   1>相互关联的数据的集合   2>较少的数据冗余   3>程序与数据相互独立   4>保证数据的安全、可靠   5>最大限度地保证数据的正确性   6>数据可以并发使用并能同时保证一致性 3、数据库管理系统的基本功能   1>数据定义     定义数据类型等   2>数据处理     增删改查等   3>数据安全     权限控制等   4>数据备份     备份还原等 4、数据库系统架构   1>单机架构   2>大型主机/终端架构   3>主从架构(C/S)     目前主流,用户访问量成为瓶颈   4>分布式架构     解决用户访问量瓶颈 5、关系型数据库   1>关系:关系就是二维表,满足如下性质:     表中的行、列次序并不重要   2>行row:表中的每一行,又称为一条记录(record)   3>列column:表中的每一列,成为属性,字段   4>主键(Primary key):用于唯一确定一个记录的字段,避免出现一样的字段   5

sql优化工具SQLAdvisor的安装

核能气质少年 提交于 2020-05-02 00:31:05
原文地址:https://www.cnblogs.com/beliveli/articles/6541936.html 本机安装包路径: D:\share\src\linux-mysql\sqlAdvisor\ 1.克隆代码 git clone https://github.com/Meituan-Dianping/SQLAdvisor.git 2.安装依赖 yum install -y cmake libaio-devel libffi-devel glib2 glib2-devel bison 3.安装percona56 yum install http://www.percona.com/downloads/percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm -y yum install Percona-Server-shared-56 -y 4.编译sqladvisor时依赖perconaserverclient_r, 因此需要安装Percona-Server-shared-56。有可能需要配置软链接例如: cd /usr/lib64/ ln -s libperconaserverclient_r.so.18 libperconaserverclient_r.so 5.

percona-toolki安装冲突(my.cnf Percona-Server-shared与mysql-community-server)

只谈情不闲聊 提交于 2020-04-27 21:55:05
最近在安装percona-toolkit工具包时,提示在my.cnf文件中, Percona-Server-shared与mysql-community-server冲突。起初还以为是一定需安装Percona-Server-shared这样一个包才可以呢。Google了一下,原来是需要安装mysql-community-libs-compat 才可以搞定。下面是对这个问题展开描述。 1、故障现象 [root@centos7 ~]# yum install percona-toolkit -y Transaction check error: file /etc/my.cnf from install of Percona-Server-shared-56-5.6.40-rel84.0.el7.x86_64 conflicts with file from package mysql-community-server-5.7.23-1.el7.x86_64 2、本地环境检查 [root@centos7 ~]# more /etc/redhat-release CentOS Linux release 7.2.1511 (Core) [root@centos7 ~]# rpm -qa|grep -i mysql mysql-community-client-5.7.23-1.el7

MySQL5.7 如何找出占用CPU高的SQL

核能气质少年 提交于 2020-04-26 11:41:47
https://www.percona.com/blog/2020/04/23/a-simple-approach-to-troubleshooting-high-cpu-in-mysql/ One of our customers recently asked whether it is possible to identify, from the MySQL side, the query that is causing high CPU usage on his system. The usage of simple OS tools to find the culprit has been a widely used technique for a long time by PostgreSQL and Oracle DBAs, but it didn’t work for MySQL as historically we’ve lacked the instrumentation to match an OS thread with an internal processlist thread – until recently. Percona added support to map processlist ids to OS thread ids through

Mysql基础

别来无恙 提交于 2020-04-23 00:42:54
1. 关系型数据库介绍 1.1 数据结构模型 数据结构模型主要有: 层次模型 网状结构 关系模型 关系模型: 二维关系:row,column 数据库管理系统:DBMS DBMS: DataBase Manager system 关系:Relational,RDBMS RDBMS: Relational DataBase Manager system 1.2 RDBMS专业名词 常见的关系型数据库管理系统: MySQL:MySQL,MariaDB,Percona-Server PostgreSQL:简称为pgsql Oracle MSSQL 记录 :数据库中表的每行是一条记录 事务 :多个操作被当作一个整体对待就称为一个事务 要看一个关系型数据库是否支持事务,需要看其是否支持并满足ACID测试 ACID:ACID是事务的一个基本标准 A:Automicity,原子性 C:Consistency,一致性 I:Isolation,隔离性 D:Durability,持久性 ACID:了解详细说明, acid(数据库事务正确执行的四个基本要素的缩写) ACID,指数据库事务正确执行的四个基本要素的缩写。包含:原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)。一个支持事务(Transaction)的数据库

MySQL 5.6表空间传输

廉价感情. 提交于 2020-04-11 10:49:02
在MySQL 5.6 Oracle引入了一个可移动表空间的特征(复制的表空间到另一个服务器)和Percona Server采用部分备份,这意味着你现在可以备份单个数据库或表;由于Percona Server 5.6的出现,innodb_import_table_from_xtrabackup是过时的Percona Server实现Oracle MySQL的可移动表空间的功能,就是在服务器之间复制的表空间的能力(table.ibd)。让我展示通过一个例子,我将采取选择性表部分备份而不是一个完整的MySQL服务器并且在线恢复它,而不需要关闭MySQL服务器 该实验用到一个备份工具percona xtrabackup,是一个开源且免费的MySQL数据库热备份软件,执行非阻塞InnoDB和xtradb数据库备份,想当好用, 最重要Percona支持部分备份模式,对应于特定的数据库或表格备份。 本实验环境: 服务器端版本:percona-5.6.21版本(下载地址: http://www.percona.com/downloads/Percona-Server-5.6/Percona-Server-5.6.21-70.1/binary/tarball/Percona-Server-5.6.21-rel70.1-698.Linux.x86_64.tar.gz ) 附加:percona-5.5

技术分享 | MySQL:查询字段数量多少对查询效率的影响

让人想犯罪 __ 提交于 2019-12-30 18:02:14
【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 作者:高鹏 文章末尾有他著作的《深入理解 MySQL 主从原理 32 讲》,深入透彻理解 MySQL 主从,GTID 相关技术知识。 这个问题是最近一个朋友问我的。刚好就好好看了一下,留下这样的记录。本文给出一些函数接口,末尾给出一些调用堆栈,为感兴趣的朋友做一个参考,也为自己做一个笔记。 一、问题由来 我们知道执行计划的不同肯定会带来效率的不同,但是在本例中执行计划完全一致,都是全表扫描,不同的只有字段个数而已。其次,测试中都使用了where 条件进行过滤(Using where),过滤后没有数据返回,我们常说的 where 过滤实际上是在 MySQL 层,当然某些情况下使用 ICP 会提前在 Innodb 层过滤数据,这里我们先不考虑 ICP,我会在后面的文章中详细描述 ICP 的流程,本文也会给出 where 过滤的接口,供大家参考。 下面的截图来自两个朋友,感谢他们的测试和问题提出。另外对于大数据量访问来讲可能涉及到物理 IO,首次访问和随后的访问因为 Innodb buffer 的关系,效率不同是正常,需要多测试几次。 测试1: 测试2: 我们通过这两个测试,可以发现随着字段的不断减少,效率越来越高,并且主要的区别都在 sending data 下面,这个状态我曾经大概描述过参考文章: https:/