InnoDB

1.mysql 官网： https://www.mysql.com/ 2. 解压与安装 [root@python ~]# tar xf /usr/local/src/mysql-5.6.42-linux-glibc2.12-x86_64.tar.gz -C /mysql/ [root@python ~]# yum install -y libaio Loaded plugins: fastestmirror, refresh-packagekit, security Setting up Install Process Loading mirror speeds from cached hostfile Package libaio-0.3.107-10.el6.x86_64 already installed and latest version Nothing to do [root@python mysql-5.6.42-linux-glibc2.12-x86_64]# pwd /mysql/mysql-5.6.42-linux-glibc2.12-x86_64 shell> groupadd mysql shell > useradd -r -g mysql -s /bin/ false mysql shell > cd /usr/ local shell > tar

为什么要分库分表和读写分离？ 类似淘宝网这样的网站，海量数据的存储和访问成为了系统设计的瓶颈问题，日益增长的业务数据，无疑对数据库造成了相当大的负载，同时对于系统的稳定性和扩展性提出很高的要求。随着时间和业务的发展，数据库中的表会越来越多，表中的数据量也会越来越大，相应地，数据操作的开销也会越来越大；另外，无论怎样升级硬件资源，单台服务器的资源（CPU、磁盘、内存、网络IO、事务数、连接数）总是有限的，最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。分表、分库和读写分离可以有效地减小单台数据库的压力。 分库分表的原理和实现 1.什么是分区、分表、分库 分区 就是把一张表的数据分成N个区块，在逻辑上看最终只是一张表，但底层是由N个物理区块组成的，分区实现比较简单，数据库mysql、oracle等很容易就可支持。 分表 就是把一张表按一定的规则分解成N个具有独立存储空间的实体表。系统读写时需要根据定义好的规则得到对应的字表明，然后操作它。 分库 一旦分表，一个库中的表会越来越多 将整个数据库比作图书馆，一张表就是一本书。当要在一本书中查找某项内容时，如果不分章节，查找的效率将会下降。而同理，在数据库中就是分区。 2.什么时候考虑使用分区？ 一张表的查询速度已经慢到影响使用的时候。 sql经过优化 数据量大 表中的数据是分段的 对数据的操作往往只涉及一部分数据，而不是所有的数据

mysql 5.7.25 安装简介 1 卸载linux系统上自带的mysql插件（old版本） rpm -qa|grep -i mysql rpm –ev {包名} --nodeps 2 删除老版本mysql相关的安装目录命令 find / -name mysql rm –rf {目录名} 3 安装包下载 官网下载 mysql-5.7.25-linux-glibc2.12-x86_64.tar.gz 编译过的安装包 tar -xzvf mysql-5.7.25-linux-glibc2.12-x86_64.tar.gz mv mysql-5.7.25-linux-glibc2.12-x86_64 /usr/local/mysql 4 主目录权限处理 查看组和用户情况 cat /etc/group | grep mysql cat /etc/passwd |grep mysql 删除原mysql用户：userdel -r mysql，会删除其对应的组和用户 创建mysql组和mysql用户 groupadd mysql useradd -r -g mysql mysql chown -R mysql:mysql /usr/local/mysql （同理对应/var/lib/mysql） 5 修改配置文件：/etc/my.cnf 主库 [client] #client

点击上方“蓝色字体”，选择“设为星标” 做积极的人，而不是积极废人！ 转载于：Java技术前线 来源：r6a.cn/bZSY 前言 在mysql中设计表的时候,mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一，单机递增),而是推荐连续自增的主键id,官方的推荐是auto_increment,那么为什么不建议采用uuid,使用uuid究竟有什么坏处？ 本篇博客我们就来分析这个问题,探讨一下内部的原因。 一、mysql和程序实例 1.1.要说明这个问题,我们首先来建立三张表 分别是user_auto_key,user_uuid,user_random_key,分别表示自动增长的主键,uuid作为主键,随机key作为主键,其它我们完全保持不变. 根据控制变量法,我们只把每个表的主键使用不同的策略生成,而其他的字段完全一样，然后测试一下表的插入速度和查询速度： 注：这里的随机key其实是指用雪花算法算出来的前后不连续不重复无规律的id:一串18位长度的long值 id自动生成表： 用户uuid表 随机主键表： 1.2.光有理论不行,直接上程序,使用spring的jdbcTemplate来实现增查测试： 技术框架：springboot+jdbcTemplate+junit+hutool,程序的原理就是连接自己的测试数据库,然后在相同的环境下写入同等数量的数据

PyMySQL安装 pip install pymysql 　　 连接数据库 在进行本文以下内容之前需要注意： 你有一个MySQL数据库，并且已经启动。 你有可以连接该数据库的用户名和密码 你有一个有权限操作的database 基本使用 # 导入pymysql模块 import pymysql # 连接database conn = pymysql.connect(host=“你的数据库地址”, user=“用户名”,password=“密码”,database=“数据库名”,charset=“utf8”) # 得到一个可以执行SQL语句的光标对象 cursor = conn.cursor() # 定义要执行的SQL语句 sql = """ CREATE TABLE USER1 ( id INT auto_increment PRIMARY KEY , name CHAR(10) NOT NULL UNIQUE, age TINYINT NOT NULL )ENGINE=innodb DEFAULT CHARSET=utf8; """ # 执行SQL语句 cursor.execute(sql) # 关闭光标对象 cursor.close() # 关闭数据库连接 conn.close() # 导入pymysql模块 import pymysql # 连接database conn =

关键词：mysql复制（异步复制），mysql异步复制 核心原理： 　　mysql 复制流程原理 　　　　 　　一个事务在 mysql异步复制中的流程与生命周期 　　 　　一个事务，在传统半同步的复制流程 　　 #mysql主从基本实验 步骤目录： 　　前提 　　异步复制（asynchronous ） 　　#【0】主从均开启binlog，设置server-id 　　#【1】准备复制账户 　　#【2】在主库上，设置读锁定有效。以便获取一个一致性的快照（flush table with read lock） 　　#【3】show master status;获取主库当前的二进制日志名和偏移量pos位置。 　　#【4】备份主库还原到从库（直接copy,或者mysqldump） 　　　　　解锁主库（unlock tables;） 　　#【5】跳过从线程启动Mysql （mysqld_safe --skip-slave-start &） 　　#【6】在mysql下配置从库复制线程（change master to ） 　　#【7】在mysql下启动从线程并验证 　　#【8】开始验证 　　#【9】故障诊断 　　#【10】主从挂了怎么快速切换恢复 　　#【11】一主一从结构迁移从库架构图 　　#【12】半同步复制 　　#【13】复制的日常管理与维护 详情： 前提： 　　（0）测试环境

前面我们系统了解了一个查询语句的执行流程，并介绍了执行过程中涉及的处理模块。相信你还记得，一条查询语句的执行过程一般是经过连接器、分析器、优化器、执行器等功能模块，最后到达存储引擎。 那么一条更新语句的执行流程又是怎么样的呢? 有时候你听DBA的同事说,MySQL可以恢复到半个月内任意一秒的状态,有没有产生过好奇, 这是怎么做到的呢? 我们带着这两个问题往下看: (MySQL 逻辑架构图) 我们把MySQL的基本执行链路在拿过来进行看下, 可以确定的是, 查询的那一套流程, 更新语句也会走一遍。 在一个表上进行更新的时候，跟这个表有关的所有缓存，都会失效，这条语句会把表上的所有缓存结果都清空，所以我们建议不查询缓存的原因。 接下来分析器会知道这是一条更新语句，如果更新的字段有索引，优化器会采用这个字段的索引，执行器具体负责执行，找到这一行数据，然后更新。 与查询不一样的是，更新流程会有两个重要的日志模块。redo log (重做日志) 和 binlog (归档日志)。 重要的日志模块 一、redo log 在讲redo log 之前， 我们要来回顾一篇文章《孔乙己》。 在这篇文章里，有一个酒店掌柜，有一块粉板，专门用来记录客人赊账的记录。如果赊账的人不多，掌柜可以把姓名和金额记录到粉板上。但是如果人多了，粉板记不下了，掌柜就要放下手头的工作，记录到专门的账本上。 如果有人赊账

数据库优化: 1.可以在单个SQL语句，整个应用程序，单个数据库服务器或多个联网数据库服务器的级别进行优化 2.数据库性能取决于数据库级别的几个因素，例如表，查询和配置设置 3.在数据库级别进行优化,在硬件级别进行优化,平衡可移植性和性能 4.合适的结构,合适的数据类型;执行频繁更新的应用程序大量表(少列);分析大量数据的应用程序少量表(多列);选择合适的存储引擎和索引; 5.压缩适用于InnoDB表的各种工作负载，以及只读MyISAM表 6.选择合适的锁定策略;InnoDB存储引擎可以处理大多数锁定问题 7.配置的主要内存区域是InnoDB缓冲池和MyISAM密钥缓存。 8.优化select语句,这方面技巧同样适用于其他带where的delete语句等,在where子句的列上设置索引;索引对于引用多个列如join和外键尤其重要 select where子句优化: 1.调整查询的结构,例如函数调用,为结果集中的每一行只调用一次,为表中的每一行只调用一次 2.减少查询中的全表扫描数 3.定期使用ANALYZE TABLE语句使表统计信息保持最新 4.了解特定于每个表的存储引擎的调优技术，索引技术和配置参数 5.优化InnoDB表的单查询事务 6.通过阅读EXPLAIN计划并调整索引，WHERE子句，连接子句等来调查特定查询的内部详细信息 7

前言 是什么原因导致线上数据库服务器磁盘I/O的util和iowait持续飚高？ 1. 问题描述 朋友小明的线上数据库突发严重告警，业务方反馈写入数据一直堵住，很多锁超时回滚了，不知道怎么回事，就找到我了。 不管3721，先采集现场的必要信息再说。 a. 系统负载，主要是磁盘I/O的负载数据  该服务器的磁盘是由6块2T SSD硬盘组成的RAID-5阵列。从上面的截图来看，I/O %util已经基本跑满了，iowait也非常高，很明显磁盘I/O压力太大了。那就再查查什么原因导致的这么高压力。 b. 活跃事务列表 可以看到，有几个活跃的事务代价很高，锁定了很多行。其中有两个因为太久超时被回滚了。 再看一次活跃事务列表，发现有个事务锁定的行更多了，说明活跃业务SQL的效率不太好，需要进行优化。这个算是原因之一，先记下。 c. 查看InnoDB状态 执行 SHOW ENGINE INNODB STATUS\G 查看InnoDB状态，这里只展示了几个比较关键的地方： ... 0x7f8f700e9700 INNODB MONITOR OUTPUT ... LATEST DETECTED DEADLOCK ------------------------ ... *** (2) TRANSACTION: TRANSACTION 52970892097, ACTIVE 1 sec