高性能MySql

今天在公司做了一个分享,发上来大家探讨一下! 高性能MySQL(上),布布扣,bubuko.com

1.锁 为什么需要锁?因为数据库要解决并发控制问题.在同一时刻,可能会有多个客户端对表中同一行记录进行操作,比如有的在读取该行数据,其他的尝试去删除它.为了保证数据的一致性,数据库就要对这种并发操作进行控制,因此就有了锁的概念. 1.1锁的分类 从对数据操作的类型(读\写)分 读锁(共享锁):针对同一块数据,多个读操作可以同时进行而不会互相影响. 写锁(排他锁):当前写操作没有完成前,它会阻断其他写锁和读锁. 大多数时候,MySQL锁的内部管理都是透明的. 1.2锁粒度(Lock granula

Schema与数据类型优化 选择优化的数据类型 下面是一些简单的原则: 更小的通常更好 一般情况下,应该尽量使用可以正确存储的最小数据类型.如:只需要存储0-200, tinyint unsigned就比较好.小的数据类型占的磁盘.内存和CPU缓存都较少,并且处理时需要的CPU周期数也更少. 简单就好 简单数据类型额操作通常需要更少的CPU周期.如:应该使用MySQL的內建类型来存储时间和日期而不是字符串.如:应该用整型存储IP地址. 尽量避免null 通常情况下最好指定列为NOT NULL,除

温习<高性能MySQL>的复制篇. 1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取

温习<高性能MySQL>的复制篇. 1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取

针对数据库的优化,我们不能单纯的说从哪一个方面,需要结合数据表的建立,数据类型的选择,索引的设计和sql语句来考虑,我就针对怎么建表,怎么选择数据类型,如何应用B-tree索引,hash索引和覆盖索引的特点来建立高效的索引策略,然后我具体对 count()查询,最大最小值查询,关联查询,子查询,GROUP BY ,limit 分页,Union查询做一些具体的说明,最后我说一下怎样使用切分查询和分解关联查询来重构我们的查询方式, 一.数据表的设计 首先我们要根据范式化和反范式化各自的优缺点,选择一

MySQL有大量可以修改的参数--但不应该随便去修改.通常只需要把基本的项配置正确(大部分情况下只有很少一些参数是真正重要的),应该将更多的时间花在schema的优化.索引,以及查询设计上.在正确地配置了MySQL的基本配置项之后,再花力气去修改其它配置项的收益通常就比较小了. 1.创建MySQL配置文件 建议不要使用操作系统的安装包自带的配置文件,最好从头开始创建一个配置文件.(首先要确定MySQL使用了哪个配置文件!) 2.InnoDB缓冲池(Buffer Pool) 有一个流行的经验法则说

1.MySQL查询缓存 很多数据库产品都能够缓存查询的执行计划,对于相同类型的SQL就可以跳过SQL解析和执行计划生成阶段.MySQL还有另一种不同的缓存类型:缓存完整的SELECT查询结果,也就是"查询缓存". 查询缓存系统会跟踪查询中涉及的每个表,如果这些表发生变化,那么和这个表相关的所有的缓存数据都将失效. 查询缓存对应用程序是完全透明的.应用程序无须关心MySQL是通过查询缓存返回的结果还是实际执行返回的结果. 另外,随着现在的通用服务器越来越强大,查询缓存可能是一个影响服务器

Btree: 1. 尽量使用覆盖索引, 即三星索引 2. 多列索引如果带范围的话, 后续列不会作为筛选条件 3. 多列索引应选择过滤性更好的充当前缀索引 4. 尽量按主键顺序插入, 减少页分裂, 采用自增ID在高并发情况下, 可能造成明显征用, 或者更改innodb_autoinc_lock_mode配置. Hash: 1.只有精确匹配所有列的查询才有效, 对于每行数据, 引擎都会对所有索引列计算hash码 2. 只有memory才可以支持hash索引, innodb支持自适应hash索引, 但

许多高性能的站点都用了"分解连接"技术,也就是把单个多表连接查询改成多个但表查询,然后在程序中合并数据,比如: select a.*,b.* from A a join B b on a.id = b.id 可以替换为: select a.* from A; select b.* from B; 然后再把数据通过程序合并. 可能有些人认为这太浪费了,把一个查询语句变成两条查询语句或者更多的查询语句了,如果哪位猿类这样想了,那你就应该继续往下看了. 将连接查询重构为多表查询,总体有以下性