超详细MySQL数据库优化
数据库优化一方面是找出系统的瓶颈,提高MySQL数据库的整体性能,而另一方面需要合理的结构设计和参数调整,以提高用户的相应速度,同时还要尽可能的节约系统资源,以便让系统提供更大的负荷
1 优化一览图
2 优化
笔者将优化分为了两大类,软优化和硬优化,软优化一般是操作数据库即可,而硬优化则是操作服务器硬件及参数设置
21 软优化
211 查询语句优化
1首先我们可以用EXPLAIN或DESCRIBE(简写:DESC)命令分析一条查询语句的执行信息
2例:
显示:
其中会显示索引和查询数据读取数据条数等信息
212 优化子查询
在MySQL中,尽量使用JOIN来代替子查询因为子查询需要嵌套查询,嵌套查询时会建立一张临时表,临时表的建立和删除都会有较大的系统开销,而连接查询不会创建临时表,因此效率比嵌套子查询高
213 使用索引
索引是提高数据库查询速度最重要的方法之一,关于索引可以参高笔者<MySQL数据库索引>一文,介绍比较详细,此处记录使用索引的三大注意事项:
214 分解表
对于字段较多的表,如果某些字段使用频率较低,此时应当,将其分离出来从而形成新的表,
215 中间表
对于将大量连接查询的表可以创建中间表,从而减少在查询时造成的连接耗时
216 增加冗余字段
类似于创建中间表,增加冗余也是为了减少连接查询
217 分析表,,检查表,优化表
分析表主要是分析表中关键字的分布,检查表主要是检查表中是否存在错误,优化表主要是消除删除或更新造成的表空间浪费
1 分析表: 使用 ANALYZE 关键字,如ANALYZE TABLE user;
2 检查表: 使用 CHECK关键字,如CHECK TABLE user [option]
option 只对MyISAM有效,共五个参数值:
3 优化表:使用OPTIMIZE关键字,如OPTIMIZE [LOCAL|NO_WRITE_TO_BINLOG] TABLE user;
LOCAL|NO_WRITE_TO_BINLOG都是表示不写入日志,优化表只对VARCHAR,BLOB和TEXT有效,通过OPTIMIZE TABLE语句可以消除文件碎片,在执行过程中会加上只读锁
22 硬优化
221 硬件三件套
1配置多核心和频率高的cpu,多核心可以执行多个线程
2配置大内存,提高内存,即可提高缓存区容量,因此能减少磁盘I/O时间,从而提高响应速度
3配置高速磁盘或合理分布磁盘:高速磁盘提高I/O,分布磁盘能提高并行操作的能力
222 优化数据库参数
优化数据库参数可以提高资源利用率,从而提高MySQL服务器性能MySQL服务的配置参数都在mycnf或myini,下面列出性能影响较大的几个参数
223 分库分表
因为数据库压力过大,首先一个问题就是高峰期系统性能可能会降低,因为数据库负载过高对性能会有影响。另外一个,压力过大把你的数据库给搞挂了怎么办?所以此时你必须得对系统做分库分表 + 读写分离,也就是把一个库拆分为多个库,部署在多个数据库服务上,这时作为主库承载写入请求。然后每个主库都挂载至少一个从库,由从库来承载读请求。
224 缓存集群
如果用户量越来越大,此时你可以不停的加机器,比如说系统层面不停加机器,就可以承载更高的并发请求。然后数据库层面如果写入并发越来越高,就扩容加数据库服务器,通过分库分表是可以支持扩容机器的,如果数据库层面的读并发越来越高,就扩容加更多的从库。但是这里有一个很大的问题:数据库其实本身不是用来承载高并发请求的,所以通常来说,数据库单机每秒承载的并发就在几千的数量级,而且数据库使用的机器都是比较高配置,比较昂贵的机器,成本很高。如果你就是简单的不停的加机器,其实是不对的。所以在高并发架构里通常都有缓存这个环节,缓存系统的设计就是为了承载高并发而生。所以单机承载的并发量都在每秒几万,甚至每秒数十万,对高并发的承载能力比数据库系统要高出一到两个数量级。所以你完全可以根据系统的业务特性,对那种写少读多的请求,引入缓存集群。具体来说,就是在写数据库的时候同时写一份数据到缓存集群里,然后用缓存集群来承载大部分的读请求。这样的话,通过缓存集群,就可以用更少的机器资源承载更高的并发。
一个完整而复杂的高并发系统架构中,一定会包含:各种复杂的自研基础架构系统。各种精妙的架构设计因此一篇小文顶多具有抛砖引玉的效果,但是数据库优化的思想差不多就这些了
目前,商品化的数据库管理系统以关系型数据库为主导产品,技术比较成熟。面向对象的数据库管理系统虽然技术先进,数据库易于开发、维护,但尚未有成熟的产品。国际国内的主导关系型数据库管理系统有Oracle、Sybase、INFORMIX和INGRES。这些产品都支持多平台,如 UNIX、VMS、Windows,但支持的程度不一样。IBM的DB2也是成熟的关系型数据库。但是,DB2是内嵌于IBM的AS/400系列机中,只支持OS/400操作系统。
1MySQL
MySQL是最受欢迎的开源SQL数据库管理系统,它由 MySQL AB开发、发布和支持。MySQL AB是一家基于MySQL开发人员的商业公司,它是一家使用了一种成功的商业模式来结合开源价值和方法论的第二代开源公司。MySQL是MySQL AB的注册商标。
MySQL是一个快速的、多线程、多用户和健壮的SQL数据库服务器。MySQL服务器支持关键任务、重负载生产系统的使用,也可以将它嵌入到一个大配置(mass- deployed)的软件中去。
与其他数据库管理系统相比,MySQL具有以下优势:
(1)MySQL是一个关系数据库管理系统。
(2)MySQL是开源的。
(3)MySQL服务器是一个快速的、可靠的和易于使用的数据库服务器。
(4)MySQL服务器工作在客户/服务器或嵌入系统中。
(5)有大量的MySQL软件可以使用。
2SQL Server
SQL Server是由微软开发的数据库管理系统,是Web上最流行的用于存储数据的数据库,它已广泛用于电子商务、银行、保险、电力等与数据库有关的行业。
目前最新版本是SQL Server 2005,它只能在Windows上运行,操作系统的系统稳定性对数据库十分重要。并行实施和共存模型并不成熟,很难处理日益增多的用户数和数据卷,伸缩性有限。
SQL Server 提供了众多的Web和电子商务功能,如对XML和Internet标准的丰富支持,通过Web对数据进行轻松安全的访问,具有强大的、灵活的、基于Web的和安全的应用程序管理等。而且,由于其易操作性及其友好的操作界面,深受广大用户的喜爱。
3Oracle
提起数据库,第一个想到的公司,一般都会是Oracle(甲骨文)。该公司成立于1977年,最初是一家专门开发数据库的公司。Oracle在数据库领域一直处于领先地位。 1984年,首先将关系数据库转到了桌面计算机上。然后,Oracle5率先推出了分布式数据库、客户/服务器结构等崭新的概念。Oracle 6首创行锁定模式以及对称多处理计算机的支持……最新的Oracle 8主要增加了对象技术,成为关系—对象数据库系统。目前,Oracle产品覆盖了大、中、小型机等几十种机型,Oracle数据库成为世界上使用最广泛的关系数据系统之一。
Oracle数据库产品具有以下优良特性。
(1)兼容性
Oracle产品采用标准SQL,并经过美国国家标准技术所(NIST)测试。与IBM SQL/DS、DB2、INGRES、IDMS/R等兼容。
(2)可移植性
Oracle的产品可运行于很宽范围的硬件与操作系统平台上。可以安装在70种以上不同的大、中、小型机上;可在VMS、DOS、UNIX、Windows等多种操作系统下工作。
(3)可联结性
Oracle能与多种通讯网络相连,支持各种协议(TCP/IP、DECnet、LU62等)。
(4)高生产率
Oracle产品提供了多种开发工具,能极大地方便用户进行进一步的开发。
(5)开放性
Oracle良好的兼容性、可移植性、可连接性和高生产率使Oracle RDBMS具有良好的开放性。
4Sybase
1984年,Mark B Hiffman和Robert Epstern创建了Sybase公司,并在1987年推出了Sybase数据库产品。Sybase主要有三种版本:一是UNIX操作系统下运行的版本; 二是Novell Netware环境下运行的版本;三是Windows NT环境下运行的版本。对UNIX操作系统,目前应用最广泛的是SYBASE 10及SYABSE 11 for SCO UNIX。
Sybase数据库的特点:
(1)它是基于客户/服务器体系结构的数据库。
(2)它是真正开放的数据库。
(3)它是一种高性能的数据库。
5DB2
DB2是内嵌于IBM的AS/400系统上的数据库管理系统,直接由硬件支持。它支持标准的SQL语言,具有与异种数据库相连的GATEWAY。因此它具有速度快、可靠性好的优点。但是,只有硬件平台选择了IBM的AS/400,才能选择使用DB2数据库管理系统。
DB2能在所有主流平台上运行(包括Windows),最适于海量数据。
DB2在企业级的应用最为广泛,在全球的500家最大的企业中,几乎85%以上都用DB2数据库服务器,而国内到1997年约占5%。
除此之外,还有微软的 Access数据库、FoxPro数据库等。既然现在有这么多的数据库系统,那么在游戏编程时应该选择什么样的数据库呢?首要的原则就是根据实际需要,另一方面还要考虑游戏开发预算。现在常用的数据库有:SQL Server、My SQL、Oracle、FoxPro。其中MySQL是一个完全免费的数据库系统,其功能也具备了标准数据库的功能,因此,在独立制作时,建议使用。 Oracle虽然功能强劲,但它毕竟是为商业用途而存在的,目前很少在游戏中使用到。
mysql的高并发其实是基于硬件的
这个配置要和服务器的硬件配置和负载来慢慢调
没有统一配置的
简单的说一点 其他的你最好去查手册
然后根据你的业务需要来调整
default-storage-engine=INNODB //事务引擎,如果不用事务支持可以不用,速度稍慢于MYSIM
max_connections=20000 //这个需要看你的硬件是否足够牛
query_cache_size=440M //查询的缓存 如果内存够大可以再大点
table_cache=2028 //表的缓存 表如果很对的话可以大点
tmp_table_size=512M //临时表空间,看你的应用了,是否用了临时表
thread_cache_size=80 //线程缓存 看你的业务是否有很多重复的请求
myisam_max_sort_file_size=100G //排序或索引文件的最大值(看你的表友多少数据和有多少索引)
后面的查手册吧 这东西设置太高太低都不太好 ,从小到大按业务需要慢慢调整吧
Tips:最好不要在主库上数据库备份,大型活动前取消这样的计划。
效率低下的sql:超高的QPS与TPS。
大量的并发:数据连接数被占满(max_connection默认100,一般把连接数设置得大一些)。
并发量:同一时刻数据库服务器处理的请求数量
超高的CPU使用率:CPU资源耗尽出现宕机。
磁盘IO:磁盘IO性能突然下降、大量消耗磁盘性能的计划任务。解决:更快磁盘设备、调整计划任务、做好磁盘维护。
13 网卡流量:如何避免无法连接数据库的情况
减少从服务器的数量(从服务器会从主服务器复制日志)
进行分级缓存(避免前端大量缓存失效)
避免使用select 进行查询
分离业务网络和服务器网络
14 大表带来的问题(重要)
141 大表的特点
记录行数巨大,单表超千万
表数据文件巨大,超过10个G
142 大表的危害
1慢查询:很难在短时间内过滤出需要的数据
查询字区分度低 -> 要在大数据量的表中筛选出来其中一部分数据会产生大量的磁盘io-> 降低磁盘效率
2对DDL影响:
建立索引需要很长时间:
MySQL -v<55建立索引会锁表
MySQL -v>=55建立索引会造成主从延迟(mysql建立索引,先在组上执行,再在库上执行)
修改表结构需要长时间的锁表:会造成长时间的主从延迟(‘480秒延迟‘)
143 如何处理数据库上的大表
分库分表把一张大表分成多个小表
难点:
分表主键的选择
分表后跨分区数据的查询和统计
15 大事务带来的问题(重要)
151 什么是事务
152事务的ACID属性
1、原子性(atomicity):全部成功,全部回滚失败。银行存取款。
2、一致性(consistent):银行转账的总金额不变。
3、隔离性(isolation):
隔离性等级:
未提交读(READ UNCOMMITED)脏读,两个事务之间互相可见;
已提交读(READ COMMITED)符合隔离性的基本概念,一个事务进行时,其它已提交的事物对于该事务是可见的,即可以获取其它事务提交的数据。
可重复读(REPEATABLE READ)InnoDB的默认隔离等级。事务进行时,其它所有事务对其不可见,即多次执行读,得到的结果是一样的!
可串行化(SERIALIZABLE) 在读取的每一行数据上都加锁,会造成大量的锁超时和锁征用,严格数据一致性且没有并发是可使用。
查看系统的事务隔离级别:show variables like ‘%iso%‘;
开启一个新事务:begin;
提交一个事务:commit;
修改事物的隔离级别:set session tx_isolation=‘read-committed‘;
4、持久性(DURABILITY):从数据库的角度的持久性,磁盘损坏就不行了
redo log机制保证事务更新的一致性和持久性
153 大事务
运行时间长,操作数据比较多的事务;
风险:锁定数据太多,回滚时间长,执行时间长。
锁定太多数据,造成大量阻塞和锁超时;
回滚时所需时间比较长,且数据仍然会处于锁定;
如果执行时间长,将造成主从延迟,因为只有当主服务器全部执行完写入日志时,从服务器才会开始进行同步,造成延迟。
解决思路:
避免一次处理太多数据,可以分批次处理;
移出不必要的SELECT操作,保证事务中只有必要的写操作。
二、什么影响了MySQL性能(非常重要)
21 影响性能的几个方面
服务器硬件。
服务器系统(系统参数优化)。
存储引擎。
MyISAM: 不支持事务,表级锁。
InnoDB: 支持事务,支持行级锁,事务ACID。
数据库参数配置。
数据库结构设计和SQL语句。(重点优化)
22 MySQL体系结构
分三层:客户端->服务层->存储引擎
MySQL是插件式的存储引擎,其中存储引擎分很多种。只要实现符合mysql存储引擎的接口,可以开发自己的存储引擎!
所有跨存储引擎的功能都是在服务层实现的。
MySQL的存储引擎是针对表的,不是针对库的。也就是说在一个数据库中可以使用不同的存储引擎。但是不建议这样做。
23 InnoDB存储引擎
MySQL55及之后版本默认的存储引擎:InnoDB。
231 InnoDB使用表空间进行数据存储。
show variables like ‘innodb_file_per_table
如果innodb_file_per_table 为 ON 将建立独立的表空间,文件为tablenameibd;
如果innodb_file_per_table 为 OFF 将数据存储到系统的共享表空间,文件为ibdataX(X为从1开始的整数);
frm:是服务器层面产生的文件,类似服务器层的数据字典,记录表结构。
232 (MySQL55默认)系统表空间与(MySQL56及以后默认)独立表空间
11 系统表空间无法简单的收缩文件大小,造成空间浪费,并会产生大量的磁盘碎片。
12 独立表空间可以通过optimeze table收缩系统文件,不需要重启服务器也不会影响对表的正常访问。
21 如果对多个表进行刷新时,实际上是顺序进行的,会产生IO瓶颈。
22 独立表空间可以同时向多个文件刷新数据。
强烈建立对Innodb 使用独立表空间,优化什么的更方便,可控。
233 系统表空间的表转移到独立表空间中的方法
使用mysqldump 导出所有数据库数据(存储过程、触发器、计划任务一起都要导出 )可以在从服务器上操作。
停止MYsql 服务器,修改参数(mycnf加入innodb_file_per_table),并删除Inoodb相关文件(可以重建Data目录)。
重启MYSQL,并重建Innodb系统表空间。
重新导入数据。
或者Alter table同样可以的转移,但是无法回收系统表空间中占用的空间。
24 InnoDB存储引擎的特性
241 特性一:事务性存储引擎及两个特殊日志类型:Redo Log 和 Undo Log
Innodb是一种事务性存储引擎。
完全支持事务的ACID特性。
支持事务所需要的两个特殊日志类型:Redo Log和Undo Log
Redo Log:实现事务的持久性(已提交的事务)。
Undo Log:未提交的事务,独立于表空间,需要随机访问,可以存储在高性能io设备上。
Undo日志记录某数据被修改前的值,可以用来在事务失败时进行rollback;Redo日志记录某数据块被修改后的值,可以用来恢复未写入data file的已成功事务更新的数据。
242 特性二:支持行级锁
InnoDB支持行级锁。
行级锁可以最大程度地支持并发。
行级锁是由存储引擎层实现的。
25 什么是锁
251 锁
252 锁类型
253 锁的粒度
MySQL的事务支持不是绑定在MySQL服务器本身,而是与存储引擎相关
将table_name加表级锁命令:lock table table_name write;写锁会阻塞其它用户对该表的‘读写’操作,直到写锁被释放:unlock tables;
锁的开销越大,粒度越小,并发度越高。
表级锁通常是在服务器层实现的。
行级锁是存储引擎层实现的。innodb的锁机制,服务器层是不知道的
254 阻塞和死锁
(1)阻塞是由于资源不足引起的排队等待现象。
(2)死锁是由于两个对象在拥有一份资源的情况下申请另一份资源,而另一份资源恰好又是这两对象正持有的,导致两对象无法完成操作,且所持资源无法释放。
26 如何选择正确的存储引擎
参考条件:
事务
备份(Innobd免费在线备份)
崩溃恢复
存储引擎的特有特性
总结:Innodb大法好。
注意:尽量别使用混合存储引擎,比如回滚会出问题在线热备问题。
27 配置参数
271 内存配置相关参数
确定可以使用的内存上限。
内存的使用上限不能超过物理内存,否则容易造成内存溢出;(对于32位操作系统,MySQL只能试用3G以下的内存。)
确定MySQL的每个连接单独使用的内存。
sort_buffer_size #定义了每个线程排序缓存区的大小,MySQL在有查询、需要做排序操作时才会为每个缓冲区分配内存(直接分配该参数的全部内存);
join_buffer_size #定义了每个线程所使用的连接缓冲区的大小,如果一个查询关联了多张表,MySQL会为每张表分配一个连接缓冲,导致一个查询产生了多个连接缓冲;
read_buffer_size #定义了当对一张MyISAM进行全表扫描时所分配读缓冲池大小,MySQL有查询需要时会为其分配内存,其必须是4k的倍数;
read_rnd_buffer_size #索引缓冲区大小,MySQL有查询需要时会为其分配内存,只会分配需要的大小。
注意:以上四个参数是为一个线程分配的,如果有100个连接,那么需要×100。
MySQL数据库实例:
①MySQL是单进程多线程(而oracle是多进程),也就是说MySQL实例在系统上表现就是一个服务进程,即进程;
②MySQL实例是线程和内存组成,实例才是真正用于操作数据库文件的;
一般情况下一个实例操作一个或多个数据库;集群情况下多个实例操作一个或多个数据库。
如何为缓存池分配内存:
Innodb_buffer_pool_size,定义了Innodb所使用缓存池的大小,对其性能十分重要,必须足够大,但是过大时,使得Innodb 关闭时候需要更多时间把脏页从缓冲池中刷新到磁盘中;
总内存-(每个线程所需要的内存连接数)-系统保留内存
key_buffer_size,定义了MyISAM所使用的缓存池的大小,由于数据是依赖存储操作系统缓存的,所以要为操作系统预留更大的内存空间;
selectsum(index_length)frominformation_schematalbeswhereengine=‘myisam‘
注意:即使开发使用的表全部是Innodb表,也要为MyISAM预留内存,因为MySQL系统使用的表仍然是MyISAM表。
max_connections控制允许的最大连接数, 一般2000更大。
不要使用外键约束保证数据的完整性。
28 性能优化顺序
从上到下:
MySQL性能管理及架构设计(一):什么影响了数据库查询速度、什么影响了MySQL性能
标签:key操作系统约束mat运行内存配置inf不同的分区
对于如何选择存储引擎,可以简答的归纳为一句话:“除非需要用到某些INNODB 不具备的特性,并且没有其他办法可以替代,否则都应该选择INNODB 引擎”。例如:如果要用到全文索引,建议优先考虑INNODB加上Sphinx的组合,而不是使用支持全文索引的myisam。当然,如果不需要用到InnoDB的特性,同时其他引擎的特性能够更好的满足需求,也可以考虑一下其他存储引擎。举个例子,如果不在乎可扩展能力和并发能力,也不在乎崩溃后的数据丢失问题,却对InnoDB的空间占用比较敏感,这种场合下选择MyISAM就比较合适。
除非万不得已,否则建议不要混合使用多种存储引擎,否则可能带来一系列负责的问题,以及一些潜在的bug和边界问题。存储引擎层和服务器层的交互已经比较复杂,更不用说混合多个存储引擎了。至少,混合存储引擎对一致性备份和服务器参数配置都带来了一定的困难。
如果应用需要不同的存储引擎,请先考虑以下几个因素:
事务
如果应用中需要事务支持,那么InnoDB(或者XtraDB)是目前最稳定,并且经验证的选择。如果不需要事务,并且主要是SELECT 和 INSERT 操作,那么myisam是不错的选择。一般日志型的应用比较符合这一特性。
备份
备份的需求也会影响到存储引擎的选择。如果可以定期的关闭服务器来执行备份,那么备份的因素可以忽略。反之,如果需要在线热备份,那么选择InnoDB就是基本的要求。
崩溃恢复
数据量比较大的时候,系统崩溃后如何快速的恢复是一个需要考虑的问题。相对而言,Myisam 崩溃后发生损坏的概论比INNODB 要高很多,而且恢复速度也很慢。因此,即使不需要事务支持,很多人也选择INNODB 引擎,这也是一个非常重要的因素。
特有的特性
最后,有些应用可能依赖一些存储引擎独有的特性或者优化,比如很多应用依赖聚簇索引的优化。另外mysql 中也只有myisam 支持地理空间搜索。如果一个存储引擎拥有一些关键的特性,同时又缺乏一些必要的特性,那么有时候不得不做折中的考虑,或者在架构设计上做一些取舍。某些存储引擎无法直接支持的特性,有时候通过变通也可以满足需求。
你不需要现在就做决定,本系列接下来会提供很多关于各种存储引擎优缺点的详细描述,也会讨论一些架构设计的技巧。一般来说,可能有很多选项你还没有意识到,等阅读完本系列回头再看这些问题可能有些帮助。如果无法确定,那么就使用InnoDB ,这个默认选择是最安全的,尤其是搞不清楚具体要什么的时候。
日志型应用如何选择引擎
假如你需要实时地记录一台中心电话交换机的每一通电话日志到mysql中,或者通过Apache的mod_log_sql 模块将网站的所有访问信息直接记录到表中。这一类应用的插入速度有很高的要求,数据库不能成为瓶颈,MYISAM或者Archive存储引擎对这类应用比较适合,因为他们成本开销低,而且插入速度非常快。
如果需要对记录的日志做分析报表,则事情就会变得有趣 了。生成报表的sql很有可能会导致插入效率降低,这时候怎么办?
一种解决方法:是利用mysql内置的复制方案将数据复制一份到备份库,然后在备份库执行比较好事和cpu的查询。这样主库只用于高效的插入工作,而备份库上执行的查询也无需担心影响到日志的插入性能。当然也可以在系统负载较低的时候执行报表查询操作,但是应用在不断变化,如果依赖这个策略可能以后会导致问题。
另外一种方法: 在日志记录表的名字中包含年月的信息,比如web_logs_2015_11或者web_logs_2015_jan。这样可以在已经没有插入操作的历史表上做频繁的查询操作,而不会干扰到最新的当前表上的插入操作。
只读或者大部分情况下只读的表
有些表的数据用于编制类目或者分裂清单(如工作岗位,竞拍,不动产等)这些应用场景是典型的读多写少的业务。如果不介意MyISAM 的崩溃恢复问题,选择MyISAM 引擎是合适的。不过不要低估崩溃恢复问题的重要性,有些存储引擎不会保证将数据安全的写入磁盘中,而许多用户实际上并不清楚这样有多大的风险(MyISAM 只将数据写到内存中,然后等待操作系统定期的将数据刷出到磁盘上)。
tips:一个值得推荐的方式,是在心梗测试环境模拟真实环境,运行应用,然后拔下电源模拟崩溃测试。对崩溃恢复的第一手测试经验是无价之宝,可以避免真的崩溃时手足无措。
不要轻易相信 ‘MYISAM 比 INNODB 快’之类的经验之谈,这个结论往往不是绝对的。在很多我们已知的场景中,INNODB 的数度都可以让MYISAM 望尘莫及,尤其是用到聚簇索引,或者需要访问的数据都可以放入内存的应用。在后面的章节,读者可以了解更多影响存储引擎性能的因素(如数据大小,io请求量,主键还是二级索引等)以及这些因素对应用的影响。
当设计上述类型的应用时,建议蚕蛹InnoDB 。MyISAM 引擎在一开始可能没有任何问题,但是随着应用压力的上升,则可能迅速恶化。各种锁征用、崩溃后的数据丢失问题都会随之而来。
订单处理
如果设计订单处理,那么支持事务就必须选择。半完成的订单无法吸引应用的用户。另外一个重要的考虑点是存储引擎对外键的支持情况。InnoDB 是订单处理类应用的最佳选择。
电子公告牌和主题讨论论坛
对于mysql 的用户,主题讨论区是个很有意思的话题。当前有成百上千的基于php或者perl的免费系统可以支持主题讨论。其中大部分的数据库操作效率都不高,因为他们大多倾向于在一次请求中执行尽可能多的查询语句。另外还有部分系统设计为不采用数据库,当然也就无法利用到数据库提供的一些方便特性。主题讨论区一般都有更新计数器,并且为给个主题计算访问统计信息。多数应用只设计了几张表来保存所有的数据,所以核心表的读写压力可能非常大。为保证这些核心表的数据一致性,锁成为资源竞争的主要因素。
尽管有这些设计缺陷,但大多数应用在低负载时可以工作的很好。如果web站点的规模迅速扩展,流量随之猛增,则数据库访问可能变得非常慢。此时一个典型的解决方案是更改为支持更高读写的存储引擎,但有时用户会发现这么做反而导致系统变得更慢了。
用户可能没有意识到这是由于某些特殊的查询的缘故,典型的如:
SELECT COUNT() FROM table
问题在于,不是所有的存储引擎运行上述查询都非常快:对于MYISAM 确实会非常快,但其他的可能不行。每种引擎都能找出类似和对自己有利的例子。下一章将帮助用户分析这些情况,演示如何发现和解决存在的这类问题。
CD-ROM应用
如果要发布一个基于CD-ROM或者DVD-ROM并且使用mysql数据文件的应用,可以考虑使用MYISAM或者MYISAM压缩表,这样表之间可以隔离,兵器可以在不同介质上相互拷贝。MYISAM压缩表比未压缩表要节约很多空间,但压缩表是只读的。在某些应用中这可能是很大的问题。但如果数据放到只读戒指的场景下,压缩表的只读特性就不是问题了,这就没有理由不使用压缩表了。
大数据量
什么样的数据量算大?我们创建或者管理很多INNODB 数据库的数据量在3-5tb之间,或者更大,这是单台机器上的量,而不是一个分片(shard)的量。这些系统运行得还不错,要做到这一点需要合理的选择硬件,做好物理设计,并为服务器的io瓶颈做好规划。在这样的数据量下,如果采用myisam,崩溃后的恢复就是一个噩梦。
对于程序开发人员而言,目前使用最流行的两种后台数据库即为MySQL and SQL Server。这两者最基本的相似之处在于数据存储和属于查询系统。你可以使用SQL来访问这两种数据库的数据,因为它们都支持ANSI-SQL。还有,这两种数据库系统都支持二进制关键词和关键索引,这就大大地加快了查询速度。同时,二者也都提供支持XML的各种格式。除了在显而易见的软件价格上的区别之外,这两个产品还有什么明显的区别吗?在这二者之间你是如何选择的?让我们看看这两个产品的主要的不同之处,包括发行费用,性能以及它们的安全性。 \x0d\\x0d\根本的区别是它们遵循的基本原则 \x0d\\x0d\二者所遵循的基本原则是它们的主要区别:开放vs保守。SQL服务器的狭隘的,保守的存储引擎与MySQL服务器的可扩展,开放的存储引擎绝然不同。虽然你可以使用SQL服务器的Sybase引擎,但MySQL能够提供更多种的选择,如MyISAM, Heap, InnoDB, and Berkeley DB。MySQL不完全支持陌生的关键词,所以它比SQL服务器要少一些相关的数据库。同时,MySQL也缺乏一些存储程序的功能,比如MyISAM引擎联支持交换功能。 \x0d\\x0d\发行费用:MySQL不全是免费,但很便宜 \x0d\\x0d\当提及发行的费用,这两个产品采用两种绝然不同的决策。对于SQL服务器,获取一个免费的开发费用最常的方式是购买微软的Office或者Visual Studio的费用。但是,如果你想用于商业产品的开发,你必须还要购买SQL Server Standard Edition。学校或非赢利的企业可以不考虑这一附加的费用。 \x0d\\x0d\性能:先进的MySQL \x0d\\x0d\纯粹就性能而言,MySQL是相当出色的,因为它包含一个缺省桌面格式MyISAM。MyISAM 数据库与磁盘非常地兼容而不占用过多的CPU和内存。MySQL可以运行于Windows系统而不会发生冲突,在UNIX或类似UNIX系统上运行则更好。你还可以通过使用64位处理器来获取额外的一些性能。因为MySQL在内部里很多时候都使用64位的整数处理。Yahoo!商业网站就使用MySQL 作为后台数据库。 \x0d\\x0d\当提及软件的性能,SQL服务器的稳定性要比它的竞争对手强很多。但是,这些特性也要付出代价的。比如,必须增加额外复杂操作,磁盘存储,内存损耗等等。如果你的硬件和软件不能充分支持SQL服务器,我建议你最好选择其他如DBMS数据库,因为这样你会得到更好的结果。 \x0d\\x0d\安全功能 \x0d\\x0d\MySQL有一个用于改变数据的二进制日志。因为它是二进制,这一日志能够快速地从主机上复制数据到客户机上。即使服务器崩溃,这一二进制日志也会保持完整,而且复制的部分也不会受到损坏。 \x0d\\x0d\在SQL服务器中,你也可以记录SQL的有关查询,但这需要付出很高的代价。 \x0d\\x0d\安全性 \x0d\\x0d\这两个产品都有自己完整的安全机制。只要你遵循这些安全机制,一般程序都不会出现什么问题。这两者都使用缺省的IP端口,但是有时候很不幸,这些IP也会被一些黑客闯入。当然,你也可以自己设置这些IP端口。 \x0d\\x0d\恢复性:先进的SQL服务器 \x0d\\x0d\恢复性也是MySQL的一个特点,这主要表现在MyISAM配置中。这种方式有它固有的缺欠,如果你不慎损坏数据库,结果可能会导致所有的数据丢失。然而,对于SQL服务器而言就表现得很稳键。SQL服务器能够时刻监测数据交换点并能够把数据库损坏的过程保存下来。 \x0d\\x0d\根据需要决定你的选择 \x0d\\x0d\对于这两种数据库,如果非要让我说出到底哪一种更加出色,也许我会让你失望。以我的观点,任一对你的工作有帮助的数据库都是很好的数据库,没有哪一个数据库是绝对的出色,也没有哪一个数据库是绝对的差劲。我想要告诉你的是你应该多从你自己的需要出发,即你要完成什么样的任务?而不要单纯地从软件的功能出发。 \x0d\\x0d\如果你想建立一个NET服务器体系,这一体系可以从多个不同平台访问数据,参与数据库的管理,那么你可以选用SQL服务器。如果你想建立一个第三方站点,这一站点可以从一些客户端读取数据,那么MySQL将是最好的选择。 \x0d\\x0d\这两者数据库都能够在NET或J2EE下运行正常,同样,都能够利用RAID。 \x0d\\x0d\1,优点分析:MYSQL短小精悍,容易上手,操作简单,免费供用的。相对其它数据库有特色又实用的语法多一些。SQL怎么也算是大型数据库,稳定,能做一般大系统的数据仓库,运行速度明显比MYSQL快N多(海量数据下这个优势显而易见)。 \x0d\2,缺点分析:MYSQL难担当大系统的数据仓库,运行速度慢,不够稳定,有掉线的情况。SQL SERVER价格贵(当然没说5元盗版),使用起来比MYSQL要难一些,毕竟东西大了说道多点。 \x0d\3,按你的补充(如何登录):MySQL自己有文字界面客户端,用起来咋说也没鼠标点方便(不过习惯了也好),当然配对MYSQL有专业的客户端软件,我是用SQLYOG519版的,各种操作真的是很方便的说。SQL SERVER 就用自带的查询分析器登录了:) 两者的前提是数据库服务都带打开,而且你得知道安装时的用户名密码哦:) \x0d\\x0d\SQL-Server 2000 是微软公司开发的中型数据库,它的可视化方面做得很好,在安全性等方面功能非常强大,并且有微软的强大技术支持,当然价格比较昂贵,适合应用于中型系统。 \x0d\MySQL是 MySQL·AB开发的小型数据库,基本上具有了数据库所需的所有功能,但是功能没有SQL-Server强大,技术支持也跟不上,但是价格便宜,在满足它的许可协议的情况下可以免费使用,适合于小型系统。 \x0d\语言都是一样的(SQL)是结构化查询语言
对于包括 mysql 在内的大多数数据库系统而言
性能问题的排查主要有以下方向:
1 需求的不合理造成的性能问题
比方说,不需要实时更新的内容,被要求做成实时更新
2 架构的不合理造成的性能问题
比方说,不适合数据库保存的数据,被存放在数据库中
或者,频繁访问但是很少变更的数据,没有做缓存
3 查询语句的不合理造成的性能问题
比方说,重复执行相同的 SQL 会造成资源浪费
或者,大量复杂的 join 语句会导致查询效率低下
4 数据库设计的不合理造成的性能问题
比方说,盲目追求三范式、四范式,有时候并没有必要
5 硬件配置的不合理造成的性能问题
比方说,数据库服务器的 io 性能、CPU 、网络状况,都会影响性能
以上这些都是性能问题定位和调优的方向
0条评论