数据库性能

Django的性能优化 一，利用标准数据库优化技术 传统数据库优化技术博大精深，不同的数据库有不同的优化技巧，但重心还是有规则的。在这里算是题外话，挑两点通用的说说： 　　 索引，给关键的字段添加索引，性能能更上一层楼，如给表的关联字段，搜索频率高的字段加上索引等。Django建立实体的时候，支持给字段添加索引，具体参考Django.db.models.Field.db_index。按照经验，Django建立实体之前应该早想好表的结构，尽量想到后面的扩展性，避免后面的表的结构变得面目全非。 　　 使用适当字段类型，本来varchar就搞定的字段，就别要text类型，小细节别不关紧要，后头数据量一上去，愈来愈多的数据，小字段很可能是大问题。 二 ，了解Django的QuerySets 　　了解Django的QuerySets对象，对优化简单程序有至关重要的作用。QuerySets是有缓存的，一旦取出来，它就会在内存里呆上一段时间，尽量重用它。 # 了解缓存属性： >>> entry = Entry.objects.get(id=1) >>> entry.blog # 博客实体第一次取出，是要访问数据库的 >>> entry.blog # 第二次再用，那它就是缓存里的实体了，不再访问数据库 >>> entry = Entry.objects.get(id=1) >>> entry

对于大多数典型的 Spring/Hibernate 企业应用而言，其性能表现几乎完全依赖于持久层的性能。此篇文章中将介绍如何确认应用是否受数据库约束，同时介绍七种常用的提高应用性能的速成法。本文系 OneAPM 工程师编译整理。 如何确认应用是否受限于数据库 确认应用是否受限于数据库的第一步，是在开发环境中进行测试，并使用 VisualVM 进行监控。VisualVM 是一款包含在 JDK 中的 Java 分析器，在命令行输入 jvisualvm 即可调用。 启用 Visual VM 之后，尝试以下步骤： 双击你正在运行的应用 选择 Sampler 点击 Settings 复选框 选择 Profile only packages ，然后输入下列包： your.application.packages.* org.hibernate.* org.springframework.* your.database.driver.package , 比如 oracle.* 点击 Sample CPU 如果应用性能受限于数据库，其 CPU 分析结果看起来会像下图： 我们看到，客户端 Java 进程花在等待数据库从网络中返回结果的时间占56%。 看到数据库查询是导致应用运行缓慢的原因，其实是好兆头。Hibernate 反射调用占比32.7%是正常情况，无法进一步优化。 性能调优第一步

单机MySQL的美好时代 在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。 在那个时候，更多的都是静态网页，动态交互类型的网站不多 初期架构 | center DAL，（Data Access Layer）。其功能主要是负责数据库的访问。简单地说就是实现对数据表的Select（查询）、Insert（插入）、Update（更新）、Delete（删除）等操作。 上述架构下，我们来看看数据存储的瓶颈是什么？ 1、数据量的总大小 一个机器放不下时。（表要占空间，表的索引要占空间） 2、数据的索引（B+ Tree树）一个机器的内存放不下时库 3、访问量(读写混合)一个实例不能承受，（读写一个库） 真正意义上的库应该是主从复制，读写分离，而mysql等数据库只能自己从自己的库中读与写，也就是自己和自己玩。 如果满足了上述1 or 3个，则需要进化.. Memcached(缓存,java上还有一个ehcache)+MySQL+垂直拆分 后来，随着访问量的上升，几乎大部分使用MySQL架构的网站在数据库上都开始出现了性能问题，web程序不再仅仅专注在功能上，同时也在追求性能。程序员们开始大量的使用缓存技术来缓解数据库的压力， 优化数据库的结构和索引 。开始比较流行的是通过文件缓存来缓解数据库压力，但是当访问量继续增大的时候，多台web机器通过文件缓存不能共享

上一篇完成了lnmp的安装，本篇则可以继续完成zabbix的安装 目录 1、下载 2、安装 1、下载 下载链接： http://jaist.dl.sourceforge.net/project/zabbix/ZABBIX%20Latest%20Stable/2.2.6/zabbix-2.2.6.tar.gz 上传zabbix-2.2.6.tar.gz到服务器/usr/local目录下面 2、安装 一、创建、导入zabbix数据库 cd /usr/local/src #进入软件包下载目录 tar zxvf zabbix-2.2.6.tar.gz #解压 cd /usr/local/zabbix-2.2.6/database/mysql #进入mysql数据库创建脚本目录 ls #列出文件，可以看到有 schema.sql、images.sql、data.sql 这三个文件 mysql -u root -p #输入密码，进入MySQL控制台 create database zabbix character set utf8; #创建数据库zabbix，并且数据库编码使用utf8 GRANT USAGE ON *.* TO 'zabbix'@'localhost' IDENTIFIED BY '123456' WITH GRANT OPTION; #创建一个zabbix用户

今天我们看看，大牛是怎么思考设计 MySQL 优化方案的，在进行MySQL的优化之前，必须要了解的就是MySQL的查询过程。很多查询优化工作实际上就是遵循一些原则，让MySQL的优化器能够按照预想的合理方式运行而已。 MySQL是一个关系型数据库管理系统，由瑞典MySQL AB 公司开发，目前属于 Oracle 旗下公司。MySQL 最流行的关系型数据库管理系统，在 WEB 应用方面MySQL是最好的 RDBMS (Relational Database Management System，关系数据库管理系统) 应用软件之一。 在进行MySQL的优化之前，必须要了解的就是MySQL的查询过程，很多查询优化工作实际上就是遵循一些原则，让MySQL的优化器能够按照预想的合理方式运行而已。 一、优化的哲学 注：优化有风险，涉足需谨慎 1.1.优化可能带来的问题？ 优化不总是对一个单纯的环境进行，还很可能是一个复杂的已投产的系统； 优化手段本来就有很大的风险，只不过你没能力意识到和预见到； 任何的技术可以解决一个问题，但必然存在带来一个问题的风险； 对于优化来说解决问题而带来的问题，控制在可接受的范围内才是有成果； 保持现状或出现更差的情况都是失败！ 2.优化的需求？ 稳定性和业务可持续性，通常比性能更重要； 优化不可避免涉及到变更，变更就有风险； 优化使性能变好，维持和变差是等概率事件；

说白了，索引问题就是一个查找问题。。。 数据库 索引 ，是数据库管理系统中一个排序的 数据结构 ，以协助快速查询、更新数据库表中数据。 索引的实现通常使用B树及其变种B+树 。 在数据之外，数据库系统还维护着满足特定查找 算法 的数据结构，这些数据结构以某种方式引用（指向）数据，这样就可以在这些数据结构上实现高级查找算法。这种数据结构，就是索引。 为表设置索引要付出代价的：一是增加了数据库的存储空间，二是在插入和修改数据时要花费较多的时间(因为索引也要随之变动)。 上图展示了一种可能的索引方式。左边是数据表，一共有两列七条记录，最左边的是数据记录的物理地址（注意逻辑上相邻的记录在磁盘上也并不是一定物理相邻的）。为了加快Col2的查找，可以维护一个右边所示的二叉查找树，每个节点分别包含索引键值和一个指向对应数据记录物理地址的指针，这样就可以运用二叉查找在O(log 2 n)的复杂度内获取到相应数据。 创建索引可以大大提高系统的性能。 第一，通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。 第二，可以大大加快数据的检索速度，这也是创建索引的最主要的原因。 第三，可以加速表和表之间的连接，特别是在实现数据的参考完整性方面特别有意义。 第四，在使用分组和排序子句进行数据检索时，同样可以显著减少查询中分组和排序的时间。 第五，通过使用索引，可以在查询的过程中，使用优化隐藏器

转载： http://www.cnblogs.com/ziyiFly/archive/2008/12/24/1361380.html 一、问题的提出 　在应用系统开发初期，由于开发数据库数据比较少，对于查询SQL语句，复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，但是如果将应用系统提交实际应用后，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优化。对于海量数据，劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍，可见对于一个系统不是简单地能实现其功能就可，而是要写出高质量的SQL语句，提高系统的可用性。 　　在多数情况下，Oracle使用索引来更快地遍历表，优化器主要根据定义的索引来提高性能。但是，如果在SQL语句的where子句中写的SQL代码不合理，就会造成优化器删去索引而使用全表扫描，一般就这种SQL语句就是所谓的劣质SQL语句。在编写SQL语句时我们应清楚优化器根据何种原则来删除索引，这有助于写出高性能的SQL语句。 　　 二、SQL语句编写注意问题 　　下面就某些SQL语句的where子句编写中需要注意的问题作详细介绍。在这些where子句中，即使某些列存在索引，但是由于编写了劣质的SQL，系统在运行该SQL语句时也不能使用该索引，而同样使用全表扫描，这就造成了响应速度的极大降低

前言 你是否在为系统的数据库来一波大流量就几乎打满CPU，日常CPU居高不下烦恼？你是否在各种NoSql间纠结不定，到底该选用那种最好？今天的你就是昨天的我，这也是写这篇文章的初衷。 这篇文章是我好几个月来一直想写的一篇文章，也是一直想学习的一个内容，作为互联网从业人员，我们要知道关系型数据库（MySql、Oracle）无法满足我们对存储的所有要求，因此对底层存储的选型，对每种存储引擎的理解非常重要。同时也由于过去一段时间的工作经历，对这块有了一些更多的思考，想通过自己的总结把这块写出来分享给大家。 结构化数据、非结构化数据与半结构化数据 文章的开始，聊一下结构化数据、非结构化数据与半结构化数据，因为数据特点的不同，将在技术上直接影响存储引擎的选型。 首先是结构化数据，根据定义 结构化数据指的是由二维表结构来逻辑表达和实现的数据，严格遵循数据格式与长度规范，也称作为行数据 ，特点为：数据以行为单位，一行数据表示一个实体的信息，每一行数据的属性是相同的。例如： 因此关系型数据库完美契合结构化数据的特点，关系型数据库也是关系型数据最主要的存储与管理引擎。 非结构化数据，指的是 数据结构不规则或不完整，没有任何预定义的数据模型，不方便用二维逻辑表来表现的数据 ，例如办公文档（Word）、文本、图片、HTML、各类报表、视频音频等。 介于结构化与非结构化数据之间的数据就是半结构化数据了

一、数据库命令规范 所有数据库对象名称必须使用小写字母并用下划线分割 所有数据库对象名称禁止使用mysql保留关键字（如果表名中包含关键字查询时，需要将其用单引号括起来） 数据库对象的命名要能做到见名识意，并且最后不要超过32个字符 临时库表必须以tmp_为前缀并以日期为后缀，备份表必须以bak_为前缀并以日期(时间戳)为后缀 所有存储相同数据的列名和列类型必须一致（一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索 引失效，导致查询效率降低） 二、数据库基本设计规范 1、所有表必须使用Innodb存储引擎 没有特殊要求（即Innodb无法满足的功能如：列存储，存储空间数据等）的情况下，所有表必须使用Innodb存储引擎（mysql5.5之前默认使用Myisam，5.6以后默认的为Innodb）Innodb 支持事务，支持行级锁，更好的恢复性，高并发下性能更好 2、数据库和表的字符集统一使用UTF8 兼容性更好，统一字符集可以避免由于字符集转换产生的乱码，不同的字符集进行比较前需要进行转换会造成索引失效 3、所有表和字段都需要添加注释 使用comment从句添加表和列的备注 从一开始就进行数据字典的维护 4、尽量控制单表数据量的大小，建议控制在500万以内 500万并不是MySQL数据库的限制，过大会造成修改表结构，备份，恢复都会有很大的问题

在谈论数据库架构和数据库优化的时候，我们经常会听到“分库分表”、“分片”、“Sharding”…这样的关键词。让人感到高兴的是，这些朋友所服务的公司业务量正在（或者即将面临）高速增长，技术方面也面临着一些挑战。让人感到担忧的是，他们系统真的就需要“分库分表”了吗？“分库分表”有那么容易实践吗？为此，笔者整理了分库分表中可能遇到的一些问题，并结合以往经验介绍了对应的解决思路和建议。 垂直分表 垂直分表在日常开发和设计中比较常见，通俗的说法叫做“大表拆小表”，拆分是基于关系型数据库中的“列”（字段）进行的。通常情况，某个表中的字段比较多，可以新建立一张“扩展表”，将不经常使用或者长度较大的字段拆分出去放到“扩展表”中，如下图所示： 小结 在字段很多的情况下，拆分开确实更便于开发和维护（笔者曾见过某个遗留系统中，一个大表中包含100多列的）。某种意义上也能避免“跨页”的问题（MySQL、MSSQL底层都是通过“数据页”来存储的，“跨页”问题可能会造成额外的性能开销，这里不展开，感兴趣的朋友可以自行查阅相关资料进行研究）。 拆分字段的操作建议在数据库设计阶段就做好。如果是在发展过程中拆分，则需要改写以前的查询语句，会额外带来一定的成本和风险，建议谨慎。 垂直分库 垂直分库在“微服务”盛行的今天已经非常普及了。基本的思路就是按照业务模块来划分出不同的数据库