bitsCN.com 同时在线访问量继续增大 对于1G内存的服务器明显感觉到吃力严重时甚至每天都会死机 或者时不时的服务器卡一下 这个问题曾经困扰了我半个多月MySQL使用是很具伸缩性的算法，因此你通常能用很少的内存运行或给MySQL更多的被存以得到更好的性能。 安装好mysql后，配制文件应该在/usr/local/mysql/share/mysql目录中，配制文件有几个，有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的网站和不同配制的...
bitsCN.comMySQL查询高速缓冲查询缓存会存储SELECT查询的文本以及发送给客户端的相应结果。如果随后收到一个相同的查询，服务器从查询缓存中重新得到查询结果，而不再需要解析和执行查询。如果有一个不经常改变的表并且服务器收到该表的大量相同查询，查询缓存在这样的应用环境中十分有用。对于许多Web服务器来说存在这种典型情况，它根据数据库内容生成大量的动态页面。查询缓存不返回旧的数据。当表更改后，查询缓存值的相关条目...
bitsCN.com 当我们被人雇来监测MySQL性能时，人们希望我们能够检视一下MySQL配置然后给出一些提高建议。许多人在事后都非常惊讶，因为我们建议他们仅仅改动几个设置，即使是这里有好几百个配置项。这篇文章的目的在于给你一份非常重要的配置项清单。我们曾在几年前在博客里给出了这样的建议，但是MySQL的世界变化实在太快了！写在开始前…即使是经验老道的人也会犯错，会引起很多麻烦。所以在盲目的运用这些推荐之前，请记住下面的...
bitsCN.com MySQL 服务器硬件和操作系统调节:1. 拥有足够的物理内存来把整个InnoDB文件加载到内存中――在内存中访问文件时的速度要比在硬盘中访问时快的多。2. 不惜一切代价避免使用Swap交换分区
bitsCN.com使用PROCEDURE ANALYSE函数优化表的数据类型表需要使用何种数据类型，是需要根据应用来判断的。在MySQL中，可以使用函数PROCEDURE ANALYSE()对当前应用的表进行分析，该函数可以对数据库中列的数据类型提出优化建议，用户可以根据应用的实际情况斟酌考虑是否实施优化。以下是函数PROCEDURE ANALYSE()的使用方法：SELECT * FROM tbl_name PROCEDURE ANALYSE(); SELECT * FROM tbl_name PROCEDURE ANALYSE(16,256); 输出的...
bitsCN.com 这几天在研究mysql数据库优化，在网上查了查资料，留在这里，后面继续跟新自己的研究心得。下面是网上的一些资料在某些情况下，MySQL可以直接使用索引来满足一个 ORDER BY 或 GROUP BY 子句而无需做额外的排序。尽管 ORDER BY 不是和索引的顺序准确匹配，索引还是可以被用到，只要不用的索引部分和所有的额外的 ORDER BY 字段在 WHERE 子句中都被包括了。下列的几个查询都会使用索引来解决 ORDER BY 或 GROUP BY 部分：...
bitsCN.com1. 说到mysql，我们立刻想起它体积小、速度快、还开源的特点，所以它应用颇广。今天我们来总结一下mysql中最频繁的两个操作：插入和查询，的优化方法。2.插入：3.一、文本导入4.使用LOAD DATA INFILE从文本下载数据这将比使用插入语句快20倍。5.示例：6.load data local infile C:/Users/DELL/Desktop/Description&Data/news1.txt into table news （文件位置）7.fields terminated by , （每一字段由‘，’分隔开）8.li...
bitsCN.com 一、前提 这里的原则只是针对MySQL数据库，其他的数据库某些是殊途同归，某些还是存在差异。我总结的也是MySQL普遍的规则，对于某些特殊情况得特殊对待。在构造SQL语句的时候要养成良好的习惯。二、原则总结 原则1、仅列出需要查询的字段，这对速度不会明显的影响，主要是考虑节省应用程序服务器的内存。原来语句： select * from admin优化为： select admin_id,admin_name,admin_password from admin原则2、尽量避免在...
bitsCN.comMySQL 从5.1开始，提供了关于优化器选项的开关选项。 这样，我们可以强制在优化器糊涂的时候，关闭一些我们认为不该做的事情；或者是当我们想查看优化器为什么要这么选择的时候，可以手动关闭或者打开这些选项来进行优化策略的改变。MySQL 从5.5 和 5.6 开始，增加了更多的开关选项。 以便使查询更加优化。 下面我来一个一个解释下这些优化开关的含义以及用途。MySQL 5.1 增加以下开关：index_merge 1). index_merge_in...
bitsCN.com 殊不知，在N年前被奉为“圣经”的数据库设计3范式早就已经不完全适用了。这里我整理了一些比较常见的数据库表结构设计方面的优化技巧，希望对大家有用。 由于MySQL数据库是基于行(Row)存储的数据库，而数据库操作 IO 的时候是以 page(block)的方式，也就是说，如果我们每条记录所占用的空间量减小，就会使每个page中可存放的数据行数增大，那么每次 IO 可访问的行数也就增多了。反过来说，处理相同行数的数据，需要访...
bitsCN.comSELECT *和SELECT 字段的优化。我们先测试一下，我的测试数据库里有26万条记录。再查询一下列数：SELECT COUNT(*) FROM information_schema.columns WHERE table_schema="lezhi_data AND table_name=demo_jobs_store ;返回是43列。这个数目作为测试数据应该是可以有初步的效果的。我们先试用SELECT 一个字段来查询一下，看看响应时间是多少：我们可以看到，执行一个字段是7.724秒。我们再执行两个字段看看效果两个字段的...
MyISAM的读性能是比Innodb强MyISAM的索引和数据是分开的，并且索引是有压缩的 Innodb是索引和数据是紧密捆绑的，没有使用压缩从而会造成Innodb比MyISAM体积庞大不小MyISAM不支持外键 Innodb支持MyISAM不支持事务 Innodb支持MyISAM只支持表所 Innodb支持行锁对数据信息的存储方式不同，MyISAM创建一张表对应3个文件，Innodb则只有一个文件.frm，数据存储在ibdata1复制自己insert into tt select * from tt---------------------...
该篇是SQL优化的第4篇。这里主要表达我的一个观点是：不该存在的索引就该干掉，留着碍事在2014-3-12 15:39:01 -- 15:55:00这段时间内，在某个业务系统我们发现2个问题：这种现象在数据库中实际也是很常见，就是某个慢查询，始作俑者，执行特马慢，把后面本该很快的查询给堵住，导致系列长查询出现经诊断，我们发现某张表里存在dateline索引，该索引会让MySQL优化器选择错了执行计划，导致后续大量SQL拥堵，大概有5000条Query相互堵...
这是MySQL SQL优化的第三篇。公司某个业务系统频繁抛出问题SQL，我们对此类SQL做了基本面统计：此类SQL近期共执行了12次，最长一次花费480秒，最短286秒t1表的rows有90多万，始终会扫描这么多不需要的数据这是由于MySQL查询优化器在处理相关子查询方面存在局限性MySQL总是会将相关的外层表压到子查询中，它认为这可以更高效地查找数据行。如果是个小表，情况可能还不会引起我们注意，但是如果外层表示一个非常大的表，那么这个查询...
这是MySQL SQL优化分享第2篇，大家都很崇尚MySQL的一个强大分支Percona，真该跟风吗？ 有些时候，还是原配靠谱，小三不一定给力。我们先看下sar报告：明显地，CPU %idle 非常低，粗大事了。我们的告警邮件里显示，单条SQL执行时间长达 300秒左右。 原始SQL非常长，这里就不贴了，但要表述的一个优化技巧是，优化的第一步，就是格式化 SQL :-) 我们看下问题SQL的问题部分：? 1234567LEFT OUTER JOIN `yy_game_info` `game` ON (`t`....