1.SQL语句上优化

1.1优化SELECT语句

查询以SELECT 语句的形式执行数据库中的所有查找操作。调整这些语句是重中之重,无论是实现动态网页的亚秒级响应时

间还是缩短产生大量隔夜报告的时间。

此外SELECT语句,进行查询调谐技术也适用于结构,如 CREATE TABLE...AS SELECT, INSERT INTO...SELECT和

WHERE在条款 DELETE的语句。这些语句具有额外的性能考虑,因为它们将写操作与面向读取的查询操作结合在一起。

优化查询的主要考虑因素是:

要更快速地SELECT ... WHERE查询,首先要检查的是是否可以添加 索引。

为WHERE条款中使用的列设置索引,以加快评估,筛选和最终检索结果。

为了避免浪费磁盘空间,构建一小组索引,以加快应用程序中使用的许多相关查询。

对于引用不同表的查询,索引是特别重要的,使用 连接和 外键等功能。

您可以使用该EXPLAIN语句来确定使用哪个索引 SELECT。

隔离并调整查询的任何部分,例如函数调用,这需要花费过多的时间。

根据查询的结构,可以为结果集中的每一行调用一次函数,甚至可以为表中的每一行调用一次函数,从而大大放大效率。

尽量减少 查询中全表扫描的次数 ,特别是对于大表格。

通过ANALYZE TABLE定期使用语句来保持表的统计数据是最新的 ,所以优化器具有构建高效执行计划所需的信息。

image.png
SHOW INDEX FROM tbl_name [FROM db_name]

SHOW INDEX会返回表索引信息。其格式与ODBC中的SQLStatistics调用相似。

SHOW INDEX会返回以下字段:

**· Table**

表的名称。

**· Non_unique**

如果索引不能包括重复词,则为0。如果可以,则为1。

**· Key_name**

索引的名称。

**· Seq_in_index**

索引中的列序列号,从1开始。

**· Column_name**

列名称。

**· Collation**

列以什么方式存储在索引中。在[<u style="word-break: break-all; line-height: normal !important; text-decoration: none;">**MySQL**</u>](javascript:;)中,有值‘A’(升序)或NULL(无分类)。

**· Cardinality**

索引中唯一值的数目的估计值。通过运行ANALYZE TABLE或myisamchk -a可以更新。基数根据被存储为整数的统计数据来计数,所以即使对于小型表,该值也没有必要是精确的。基数越大,当进行联合时,MySQL使用该索引的机会就越大。

**· Sub_part**

如果列只是被部分地编入索引,则为被编入索引的字符的数目。如果整列被编入索引,则为NULL。

**· Packed**

指示关键字如何被压缩。如果没有被压缩,则为NULL。

**· Null**

如果列含有NULL,则含有YES。如果没有,则该列含有NO。

**· Index_type**

用过的索引方法(BTREE, FULLTEXT, HASH, RTREE)。

**· Comment**

多种评注。



了解针对每个表的存储引擎特定的调整技术,索引技术和配置参数。双方InnoDB并 MyISAM有两套准则的实现和维持查询高性能。

避免以难以理解的方式转换查询,特别是如果优化器自动执行一些相同的转换。

如果性能问题不能通过基本准则之一轻易解决,请通过阅读EXPLAIN计划并调整索引,WHERE子句,连接条款等来调查具

体查询的内部细节 。(当您达到一定水平的专业知识时,阅读 EXPLAIN计划可能是每个查询的第一步。)

调整MySQL用于缓存的内存区域的大小和属性。通过高效地使用 InnoDB 缓冲池, MyISAM密钥缓存和MySQL查询缓存,重

复查询运行速度更快,因为第二次和后续都会从内存中检索结果。

即使对于使用高速缓存内存区域快速运行的查询,您仍然可以进一步优化,以使它们所需的缓存内存更少,从而使您的应用

程序具有更高的可扩展性。可伸缩性意味着您的应用程序可以同时处理更多的用户,更大的请求等,而不会出现大幅下降的

性能。

处理锁定问题,其中查询速度可能会受到同时访问表的其他会话影响。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 202,802评论 5 476
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,109评论 2 379
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 149,683评论 0 335
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,458评论 1 273
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,452评论 5 364
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,505评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,901评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,550评论 0 256
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,763评论 1 296
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,556评论 2 319
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,629评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,330评论 4 318
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,898评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,897评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,140评论 1 259
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,807评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,339评论 2 342

推荐阅读更多精彩内容

  • MySQL技术内幕:InnoDB存储引擎(第2版) 姜承尧 第1章 MySQL体系结构和存储引擎 >> 在上述例子...
    沉默剑士阅读 7,379评论 0 16
  • 原文链接:http://blog.csdn.net/qq_22329521/article/details/548...
    越长越圆阅读 6,258评论 0 22
  • 系统层面(基本不用动,看了下,买的云服务器基本都已经优化过了) 内核相关参数(/etc/sysctl.conf) ...
    神奇大叶子阅读 1,992评论 0 4
  • MySQL不权威总结 欢迎阅读 本文并非事无巨细的mysql学习资料,而是选择其中重要、困难、易错的部分进行系统地...
    liufxlucky365阅读 2,566评论 0 26
  • 还记得我曾经的承诺吗 如果我忘了 你一定要帮我记得 如果我记得 你一定要使劲想起来 谁知道会是一个什么样的惊喜呢 ...
    天野丢阅读 135评论 0 0