昌平电脑培训分享提高数据库的性能

提升数据库性能可以提升查询速度，优化数据库结构，减少服务器压力等，那么如何优化数据库呢？昌平电脑培训来看看下面的文章！

1数据库I/O方面硬件性能

最有可能影响性能的是磁盘和网络吞吐量。解决办法：

·扩大虚拟内存，并保证有足够可以扩充的空间

·把数据库服务器上的不必要服务关闭掉

·把SQL数据库服务器的吞吐量调为最大

2调整数据库

·若对该表的查询频率比较高，则建立索引。

·分区(如MySQL，按时间分区)

·尽量使用固定长度字段和限制字段长度(如varchar(10))优势：

降低物理存储空间

提高数据库处理速度

附带校验数据库是否合法功能

3使用存储过程

应用程序的实现过程中，能够采用存储过程实现的对数据库的 *** 作尽量通过存储过程来实现。

因为存储过程是存放在数据库服务器上的一次性被设计、编码、测试，并被再次使用，需要执行该任务的应用可以简单地执行存储过程，并且只返回结果集或者数值。

这样不仅可以使程序模块化，同时提高响应速度，减少网络流量，并且通过输入参数接受输入，使得在应用中完成逻辑的一致性实现。

4SQL语句方面

建立查询条件索引仅仅是提高速度的前提条件，响应速度的提高还依赖于对索引的使用。不良的SQL往往来自于不恰当的索引设计、不充份的连接条件和不可优化的where子句。

·优化sql语句，减少比较次数

·限制返回条目数(mysql中使用limit)

不会有问题，现在BBS很多都是一张表存上万条，用SQL SERVER都行，更何况ORACLE了。查询的性能问题不是你的语言决定的，而是数据库决定的。数据库本身建立了索引，不会线性的去找，速度非常快的，所以没必要分开检索

进行SQL性能优化的方法：

1、SQL语句不要写的太复杂。一个SQL语句要尽量简单，不要嵌套太多层。

2、使用『临时表』缓存中间结果。简化SQL语句的重要方法就是采用临时表暂存中间结果，这样可以避免程序中多次扫描主表，也大大减少了阻塞，提高了并发性能。

3、使用like的时候要注意是否会导致全表扫，有的时候会需要进行一些模糊查询例如：select id from table where username like ‘%hollis%’关键词%hollis%，由于hollis前面用到了“%”，因此该查询会使用全表扫描，除非必要，否则不要在关键词前加%。

4、尽量避免使用!=或<> *** 作符。在where语句中使用!=或<>，引擎将放弃使用索引而进行全表扫描。

5、尽量避免使用 or 来连接条件；在 where 子句中使用 or 来连接条件，引擎将放弃使用索引而进行全表扫描。可以使用

select id from t where num=10

union all

select id from t where num=20

替代

select id from t where num=10 or num=20

6、尽量避免使用in和not in：在 where 子句中使用 in和not in，引擎将放弃使用索引而进行全表扫描。可以使用

select id from t where num between 10 and 20

替代

select id from t where num in (10,20)

7、可以考虑强制查询使用索引

select  from table force index(PRI) limit 2;(强制使用主键)

select  from table force index(hollis_index) limit 2;(强制使用索引"hollis_index")

select  from table force index(PRI,hollis_index) limit 2;(强制使用索引"PRI和hollis_index")

8、尽量避免使用表达式、函数等 *** 作作为查询条件；尽量避免大事务 *** 作，提高系统并发能力。尽量避免使用游标；任何地方都不要使用 select  from t ，用具体的字段列表代替“”，不要返回用不到的任何字段。

9、尽可能的使用 varchar/nvarchar 代替 char/nchar。尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。

10、索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率、并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引。

一段SQL代码写好以后，可以通过查看SQL的执行计划，初步预测该SQL在运行时的性能好坏，尤其是在发现某个SQL语句的效率较差时，我们可以通过查看执行计划，分析出该SQL代码的问题所在。

1、 打开熟悉的查看工具：PL/SQL Developer。

在PL/SQL Developer中写好一段SQL代码后，按F5，PL/SQL Developer会自动打开执行计划窗口，显示该SQL的执行计划。

2、 查看总COST，获得资源耗费的总体印象

一般而言，执行计划第一行所对应的COST(即成本耗费)值，反应了运行这段SQL的总体估计成本，单看这个总成本没有实际意义，但可以拿它与相同逻辑不同执行计划的SQL的总体COST进行比较，通常COST低的执行计划要好一些。

3、 按照从左至右，从上至下的方法，了解执行计划的执行步骤

执行计划按照层次逐步缩进，从左至右看，缩进最多的那一步，最先执行，如果缩进量相同，则按照从上而下的方法判断执行顺序，可粗略认为上面的步骤优先执行。每一个执行步骤都有对应的COST,可从单步COST的高低，以及单步的估计结果集（对应ROWS/基数），来分析表的访问方式，连接顺序以及连接方式是否合理。

4、 分析表的访问方式

表的访问方式主要是两种：全表扫描（TABLE ACCESS FULL）和索引扫描(INDEX SCAN)，如果表上存在选择性很好的索引，却走了全表扫描，而且是大表的全表扫描，就说明表的访问方式可能存在问题；若大表上没有合适的索引而走了全表扫描，就需要分析能否建立索引，或者是否能选择更合适的表连接方式和连接顺序以提高效率。

5、 分析表的连接方式和连接顺序

表的连接顺序：就是以哪张表作为驱动表来连接其他表的先后访问顺序。

表的连接方式：简单来讲，就是两个表获得满足条件的数据时的连接过程。主要有三种表连接方式，嵌套循环（NESTED LOOPS）、哈希连接（HASH JOIN）和排序-合并连接（SORT MERGE JOIN）。我们常见得是嵌套循环和哈希连接。

嵌套循环：最适用也是最简单的连接方式。类似于用两层循环处理两个游标，外层游标称作驱动表，Oracle检索驱动表的数据，一条一条的代入内层游标，查找满足WHERE条件的所有数据，因此内层游标表中可用索引的选择性越好，嵌套循环连接的性能就越高。

哈希连接：先将驱动表的数据按照条件字段以散列的方式放入内存，然后在内存中匹配满足条件的行。哈希连接需要有合适的内存，而且必须在CBO优化模式下，连接两表的WHERE条件有等号的情况下才可以使用。哈希连接在表的数据量较大，表中没有合适的索引可用时比嵌套循环的效率要高。

在需要支持移动/平板电脑应用及普通桌面浏览器访问的时代，网站的普及率和有效性很大程度上取决于其可用性和性能。一个访问缓慢的网站会使得访问者或潜在的客户流失，并导致商业的失败。IT培训认为一个访问速度相当快的网站将会决定访客是否会使用网站提供的产品或服务。

拥有大规模数据库的网站始终需要适当的关注、配置、优化、调整和维护，以确保网站的快速加载。这篇文章将讨论如何优化有海量数据的MySQL数据库。

选择InnoDB作为存储引擎

大型产品的数据库对于可靠性和并发性的要求较高，InnoDB作为默认的MySQL存储引擎，相对于MyISAM来说是个更佳的选择。

优化数据库结构

组织数据库的schema、表和字段以降低I/O的开销，将相关项保存在一起，并提前规划，以便随着数据量的增长，性能可以保持较高的水平。

设计数据表应尽量使其占用的空间最小化，表的主键应尽可能短。

对于InnoDB表，主键所在的列在每个辅助索引条目中都是可复制的，因此如果有很多辅助索引，那么一个短的主键可以节省大量空间。

仅创建你需要改进查询性能的索引。索引有助于检索，但是会增加插入和更新 *** 作的执行时间。

InnoDB的ChangeBuffering特性

InnoDB提供了changebuffering的配置，可减少维护辅助索引所需的磁盘I/O。大规模的数据库可能会遇到大量的表 *** 作和大量的I/O，以保证辅助索引保持最新。当相关页面不在缓冲池里面时，InnoDB的changebuffer将会更改缓存到辅助索引条目，从而避免因不能立即从磁盘读取页面而导致耗时的I/O *** 作。当页面被加载到缓冲池时，缓冲的更改将被合并，更新的页面之后会刷新到磁盘。这样做可提高性能，适用于MySQL55及更高版本。

在开始演示之前，我们先介绍下两个概念。

概念一，数据的可选择性基数，也就是常说的cardinality值。

查询优化器在生成各种执行计划之前，得先从统计信息中取得相关数据，这样才能估算每步 *** 作所涉及到的记录数，而这个相关数据就是cardinality。简单来说，就是每个值在每个字段中的唯一值分布状态。

比如表t1有100行记录，其中一列为f1。f1中唯一值的个数可以是100个，也可以是1个，当然也可以是1到100之间的任何一个数字。这里唯一值越的多少，就是这个列的可选择基数。

那看到这里我们就明白了，为什么要在基数高的字段上建立索引，而基数低的的字段建立索引反而没有全表扫描来的快。当然这个只是一方面，至于更深入的探讨就不在我这篇探讨的范围了。

概念二，关于HINT的使用。

这里我来说下HINT是什么，在什么时候用。

HINT简单来说就是在某些特定的场景下人工协助MySQL优化器的工作，使她生成最优的执行计划。一般来说，优化器的执行计划都是最优化的，不过在某些特定场景下，执行计划可能不是最优化。

比如：表t1经过大量的频繁更新 *** 作，（UPDATE,DELETE,INSERT），cardinality已经很不准确了，这时候刚好执行了一条SQL，那么有可能这条SQL的执行计划就不是最优的。为什么说有可能呢？

来看下具体演示

譬如，以下两条SQL，

A：

select from t1 where f1 = 20;

B：

select from t1 where f1 = 30;

如果f1的值刚好频繁更新的值为30，并且没有达到MySQL自动更新cardinality值的临界值或者说用户设置了手动更新又或者用户减少了sample page等等，那么对这两条语句来说，可能不准确的就是B了。

这里顺带说下，MySQL提供了自动更新和手动更新表cardinality值的方法，因篇幅有限，需要的可以查阅手册。

那回到正题上，MySQL 80 带来了几个HINT，我今天就举个index_merge的例子。

示例表结构：

mysql> desc t1;+------------+--------------+------+-----+---------+----------------+| Field      | Type         | Null | Key | Default | Extra          |+------------+--------------+------+-----+---------+----------------+| id         | int(11)      | NO   | PRI | NULL    | auto_increment || rank1      | int(11)      | YES  | MUL | NULL    |                || rank2      | int(11)      | YES  | MUL | NULL    |                || log_time   | datetime     | YES  | MUL | NULL    |                || prefix_uid | varchar(100) | YES  |     | NULL    |                || desc1      | text         | YES  |     | NULL    |                || rank3      | int(11)      | YES  | MUL | NULL    |                |+------------+--------------+------+-----+---------+----------------+7 rows in set (000 sec)

表记录数：

mysql> select count() from t1;+----------+| count() |+----------+|    32768 |+----------+1 row in set (001 sec)

这里我们两条经典的SQL：

SQL C：

select from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;

SQL D：

select from t1 where rank1 =100  and rank2 =100  and rank3 =100;

表t1实际上在rank1,rank2,rank3三列上分别有一个二级索引。

那我们来看SQL C的查询计划。

显然，没有用到任何索引，扫描的行数为32034，cost为324365。

mysql> explain  format=json select from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "324365"    },    "table": {      "table_name": "t1",      "access_type": "ALL",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "rows_examined_per_scan": 32034,      "rows_produced_per_join": 115,      "filtered": "036",      "cost_info": {        "read_cost": "323207",        "eval_cost": "1158",        "prefix_cost": "324365",        "data_read_per_join": "49K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))"    }  }}1 row in set, 1 warning (000 sec)

我们加上hint给相同的查询，再次看看查询计划。

这个时候用到了index_merge,union了三个列。扫描的行数为1103，cost为44109，明显比之前的快了好几倍。

mysql> explain  format=json select /+ index_merge(t1) / from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "44109"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "union(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1103,      "rows_produced_per_join": 1103,      "filtered": "10000",      "cost_info": {        "read_cost": "33079",        "eval_cost": "11030",        "prefix_cost": "44109",        "data_read_per_join": "473K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))"    }  }}1 row in set, 1 warning (000 sec)

我们再看下SQL D的计划：

不加HINT，

mysql> explain format=json select from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "53434"    },    "table": {      "table_name": "t1",      "access_type": "ref",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "idx_rank1",      "used_key_parts": [        "rank1"      ],      "key_length": "5",      "ref": [        "const"      ],      "rows_examined_per_scan": 555,      "rows_produced_per_join": 0,      "filtered": "007",      "cost_info": {        "read_cost": "47884",        "eval_cost": "004",        "prefix_cost": "53434",        "data_read_per_join": "176"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100))"    }  }}1 row in set, 1 warning (000 sec)

加了HINT，

mysql> explain format=json select /+ index_merge(t1)/ from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "523"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "intersect(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1,      "rows_produced_per_join": 1,      "filtered": "10000",      "cost_info": {        "read_cost": "513",        "eval_cost": "010",        "prefix_cost": "523",        "data_read_per_join": "440"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100) and (`ytt``t1``rank1` = 100))"    }  }}1 row in set, 1 warning (000 sec)

对比下以上两个，加了HINT的比不加HINT的cost小了100倍。

总结下，就是说表的cardinality值影响这张的查询计划，如果这个值没有正常更新的话，就需要手工加HINT了。相信MySQL未来的版本会带来更多的HINT。

数据查询 是数据库 *** 作中最主要的功能之一;有时候数据库查询性能的好坏 直接关系到数据库的运行效率 关系到数据库的选型 下面笔者不谈大道理 只是对其中对一些平时大家容易忽略的查询小技巧做一些总结 或许大家可能正在为此犯愁呢

第一个技巧 利用连接符连接多个字段

如在员工基本信息表中 有员工姓名 员工职位 出身日期等等 如果现在视图中这三个字段显示在同一个字段中 并且中间有分割符 如我现在想显示的结果为 经理Victor出身于 年 月 日 这该如何处理呢其实 这是比较简单的 我们可以在Select查询语句中 利用连接符把这些字段连接起来

如可以这么写查询语句

SELECT员工职位 || ||员工姓名|| 出身于 ||出身日期 as 员工出身信息 FROM 员工基本信息表;

通过这条语句就可以实现如上的需求 也就是说 我们在平时查询中 可以利用||连接符把一些相关的字段连接起来 这在报表视图中非常的有用 如笔者以前在设计图书馆管理系统的时候 在书的基本信息处有图书的出版社 出版序列号等等内容 但是 有时会在打印报表的时候 需要把这些字段合并成一个字段打印 为此 就需要利用这个连接符把这些字段连接起来 而且 利用连接符还可以在字段中间加入一些说明性的文字 以方便大家阅读 如上面我在员工职位与员工姓名之间加入了空格;并且在员工姓名与出身日期之间加入了出身于几个注释性的文字 这些功能看起来比较小 但是却可以大大的提高内容的可读性 这也是我们在数据库设计过程中需要关注的一个内容

总之 令后采用连接符 可以提高我们报表的可读性于灵活性

第二个技巧 取消重复的行

如在人事管理系统中 有员工基本信息基本表 在这张表中 可能会有部门 职位 员工姓名 身份z件号码等字段 若查询这些内容 可能不会有重复的行 但是 我若想知道 在公司内部设置了哪些部门与职位的时候 并且这些部门与职位配置了相关人员 此时 又该如何查询呢

若我现在直接查询部门表 其可以知道系统中具体设置了哪些部门与职位 但是 很有可能这些部门或者职位由于人事变动的关系 现在已经没有人了 所以 这里查询出来的是所有的部门与职位信息 而不能够保证这个部门或者职位一定有职员存在 也就是说 这不能够满足于我们上面的要求

若我现在直接从员工信息表中查询 虽然可以保证所查询出来的部门与职位信息 一定有员工信息的存在 但是 此时查询出来的部门与职位信息会有重复的行 如采购部门分工合作 可能会有采购采购小组长 此时 在查询出来的部门与职位的信息中 就会有三条重复的记录

所以 以上两种处理方式 都不能够百分之百的满足企业用户的需求 此时 我们其实可以利用一个DISTINCT函数 来消除其中查询出来的重复行

如我们可以利用SELECT DISTINCT 部门信息 职位信息 FROM 员工基本信息表 通过这条加了DISTINCT约束的查询语句 不但可以查询出所有有员工的职位与部门信息 而且 会把重复的记录过滤掉 从而提高可阅读性

所以 在数据库设计过程中 特别是在查询语句的使用中 这个函数特别有用

第三个技巧 勤用WHERE语句

我们都知道 数据库查询效率高不高 是我们评价数据库设计好坏的一个重要标准 毋庸置疑 在数据库查询中勤用Where条件语句 是提高数据库查询性能的一个很重要的手段之一 特别是在设计到比较大的表中查询符合条件的记录过程中 利用WHERE条件语句加以限制 可以大幅度的提高查询的响应速度

如在图书馆管理系统中 现在有人想查询 注册会计师 辅导用书的时候 虽然不在书的类别或者名称中输入 注册会计师 先查询出全部的纪录 然后再一条条的看是否有相关的书籍信息 也是可行的 但是 这么处理的话 一方面系统响应的速度会非常的慢 因为里面记录很多 另一方面 查询的结果看起来也会非常的头疼

其实 我们只需要在查询中加入一些查询的参数 利用Where条件语句加以限制 则即可以提高数据库响应的速度 也可以找出最符合用户需求的数据

另外 我也接触过一些在Oracle数据库上设计的平台型管理软件 他们可以自定义相关的报表 在报表设计中 只要用户在前台设计平台中 选中 大表查询 的话 则这个平台会在生成报表的时候 自动应用Where条件语句 以提高前台系统从数据库查询数据的效率

所以 笔者认为在Oracle数据库系统设计中 要勤于使用Where语句 利用Where语句来提高数据库查询的效率

第四个技巧 灵活使用COUNT函数

在查询处理的时候 COUNT函数可以说是我们应用的比较多的函数之一 如我们有时候需要统计员工的人数 统计图书的种类数的时候 都需要使用到这个函数 不过 这个函数很多人可能会用 但是到灵活应用的地步 还是有一点差距

下面笔者就COUNT函数的一些应用技巧谈谈自己的心得

一是要灵活放置COUNT函数的位置 因为利用COUNT函数统计记录数的时候 是会考虑空行的记录的 如在数据表中一般有序列字段与其它的有意义字段两类 有时候可能序列字段中有内容而其它字段中没有内容 则在利用COUNT函数统计记录数量的时候 会把这个空记录也考虑进去 很明显 则就会发生统计的错误 所以 这个COUNT函数该放在哪个位置上 还是比较讲究的 一般的话 笔者试建议不要放在序列号字段上 而要放在一些关键的实体字段中 如统计员工人数的时候 则就可以放在员工姓名或者编号上等等

二是灵活跟其它函数搭配使用 如在上面的例子中 笔者谈到有时候用户需要知道现在有员工编制的部门与职位有哪一些 我们可以利用DISTINCT函数来找出具体的部门 但是 我现在只想知道有编制的部门与职位具体有多少 此时 我们也可以利用COUNT 与DISTINCT函数结合应用 找出我们所需要的数据 在COUNT函数中 可以指定ALL与DISTINCT选项 默认的情况下 是ALL选项 表示统计所有的行 其中也包括重复的行 而DISTINCT就表示只统计不重复的行 可见 COUNT函数跟其它函数搭配使用的话 可以简化我们的查询语句 提高查询效率

第五个技巧 只查询时必须的字段

有时候 用户不同的查询需求都要用到同一张表 如在员工信息表中包含了很多内容 有时候用户想要知道正式员工有多少;管理层员工有多少;生产线员工又有哪些;或者想知道合同即将到期的员工有哪些 为此 就遇到一个问题 因为这些内容基本上都是在同一张表中 那是在同一个视图中实现 而是根据需求不同 设计不同的视图呢

若单从技术上考虑 两这都是可以实现的 不会有多大的难度 但是 若是从数据库性能上考虑在 则还是采用不同的视图来实现不同的需求为好

一方面 若从安全方面讲 则可以根据不同的视图来控制相关的访问权限 可见 把视图细化 在权限控制上则会更加的灵活

lishixinzhi/Article/program/Oracle/201311/17049

以上就是关于昌平电脑培训分享提高数据库的性能全部的内容，包括:昌平电脑培训分享提高数据库的性能、Java对数据库（Oracle）大量查询性能问题，达人指教！！！、如何进行SQL性能优化等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！