sql优化

一、总结前一天的学习 从“第三天”的性能测试一节中，我们得知了决定性能测试的几个重要指标，它们是： ü 吞吐量 ü Responsetime ü Cpuload ü MemoryUsage 我 们也在第三天的学习中对Apache做过了一定的优化，使其最优化上述4大核心指标的读数，那么我们的Apache调优了，我们的Tomcat也作些相应 的调整，当完成今的课程后，到时你的“小猫”到时真的会“飞”起来的，所以请用心看完，这篇文章一方面用来向那位曾写过“Tomcat如何承受1000个 用户”的作都的敬，一方面又是这篇原文的一个扩展，因为在把原文的知识用到相关的两个大工程中去后解决了： 1) 承受更大并发用户数 2) 取得了良好的性能与改善（系统平均性能提升达20倍，极端一个交易达80倍）。 另外值的一提的是，我们当时工程里用的“小猫”是跑在32位机下的， 也就是我们的JVM最大受到2GB内存的限制，都已经跑成“飞”了。。。。。。如果在64位机下跑这头“小猫”。。。。。。大家可想而知，会得到什么样的效果呢？下面就请请详细的设置吧！ 二、一切基于JVM（内存）的优化 2.1 32位操作系统与64位操作系统中JVM的对比 我们一般的开发人员，基本用的是都是32位的Windows系统，这就导致了一个严重的问题即：32位windows系统对内存限制，下面先来看一个比较的表格： 操作系统

PHP：PHP 5.3.6 (cli) (built: Jun 15 2011 16:29:50) 　　MYSQL：5.1.51 　　如果我们有的一张表有几百万或几千万的记录，我们要使用 PHP 将所有的记录都获取过来(遍历数据表)进行处理。查询语句： 　　SELECT * FROM largetable; 　　PS：为了证明上面的做法是最佳的办法，我尝试使用 largetable 中的一个字段做 where ，以及 LIMIT，OFFSET 。上面那种 WHERE 获得结果很慢，虽然用了索引。后面这种 LIMIT 可以让你有一种想死的感觉(有兴趣可以了解下，《分页优化》)。 　　以 MYSQL 以及PDO_MYSQL 为例，尝试直接使用以下代码，必然会出现超内存的情况： 　　 $result = mysql_query($sql); 　　while ($rowset = mysql_fetch_assoc($mysql)) { 　　... 　　$stmt = $dbh->prepare($sql); 　　$stmt->execute(); 　　while ($row = $stmt->fetch(PDO::FETCH_ASSOC, PDO::FETCH_ORI_NEXT)) { 　　... 　　 　　原因在于在查询执行后，PHP 的MYSQL、PDO_MYSQL

1、问题描述 在MySQL中我们通常会采用limit来进行翻页查询，比如limit(0,10)表示列出第一页的10条数据，limit(10,10)表示列出第二页。但是，当limit遇到order by的时候，可能会出现翻到第二页的时候，竟然又出现了第一页的记录。 SELECT `post_title`, `post_date` FROM post WHERE `post_status` = 'publish' ORDER BY view_count desc LIMIT 5, 5 　　使用上述SQL查询的时候，很有可能出现和LIMIT 0,5相同的某条记录。而如果使用如下方式，则不会出现重复的情况： SELECT * FROM post WHERE post_status = 'publish' ORDER BY view_count desc LIMIT 5, 5 但是，由于post表的字段很多，仅仅希望用这两个字段，不想把post_content也查出来。为了解决这个情况，在ORDER BY后面使用了两个排序条件来解决这个问题，如下： SELECT `post_title`, `post_date` FROM post WHERE `post_status` = 'publish' ORDER BY view_count desc, ID asc LIMIT 5, 5 按理来说

[TOC] MySQL性能管理及架构设计笔记 数据库监控 要监控的内容 对数据库的可用性进行监控: 不是仅仅监控数据库进程是否存在,要通过网络连接到数据库并确定是可用的 对数据库性能进行监控: QPS TPS, 并发线程数量, innnoDB阻塞和死锁 对主从复制进行监控: 主从链路状态, 主从延迟, 主从数据一致性 对服务器资源监控: 磁盘: 且并不意味着磁盘空间大,MySQL能用的就大,因为可能分区分配的不够大. CPU使用率 内存使用情况 swap分区使用情况 网络IO使用情况 数据库可用性监控 确认数据库是否可用通过网络正常连接 要注意,如果我们在MySQL本机使用SQL来连接MySQL,这并不意味着外部也能通过tcp/ip协议来访问MySQL,因为外部面临的环境更为复杂. 比如tcp/ip被占满之类的, 所以我们必须通过远程服务器来实际的连接请求: 使用mysqladmin: # 如果数据库存活,该命令会返回mysqld is alive ~ ⌚ 23:30:42 $ mysqladmin -u root -p -h localhost ping Enter password: mysqld is alive 使用Telnet(一般作为手动使用) # telnet连接成功后,都懂得,只要不是提示连接失败,同时提供给我们可以交互式命令行,那就是成功了 ~ ⌚ 23:42

本文源码： GitHub·点这里 || GitEE·点这里 一、服务器性能简介 1、性能定义 服务器性能优化是一项非常艰巨的任务，当然也是很难处理的问题，在写这篇文章的时候，特意请教下运维大佬，硬件工程师，数据库管理，单从自己的实际开发经验来看，看待这个问题的角度起码是不全面的。 补刀一句 ：在公司靠谱少撕逼，工程师这个群体是很好交朋友的，互相学习一起进步，升职加薪他不好吗？ 服务性能定义：完成一个任务或者处理一次接口请求所需要的时间，这个时间是指响应完成时间，即请求发出，到页面响应回显结束，这是看待性能问题的基本逻辑。 2、分析性能 服务的基本过程一般如下图，这是一张最简单的前后端分离，加一台数据库存储的流程，但是想要说明一个复杂的逻辑。 从页面请求，到获取完整的响应结果，这个过程每个环节都可能导致性能问题，抛开网络，硬件，服务器，MySQL存储这些核心客观因素，单是下面这行代码就可以秒掉很多人的努力。 Thread.sleep(10000); // 仿佛整个世界都安静了。 影响性能的因素很多，一般说性能优化会从下面几个方面考虑： 网络传输，比如私有云和公有云的交互，接口传输内容过大； 应用服务，接口设计是否最简，没有逻辑问题，架构设计是否合理； 存储服务，MySQL的查询写入，表设计是否合理，连接池配置是否合理； 硬件设施，CPU和内存的利用是否在合理区间，缓存是否合理；

1. 查找最晚入职员工的所有信息 CREATE TABLE `employees` ( `emp_no` int(11) NOT NULL, `birth_date` date NOT NULL, `first_name` varchar(14) NOT NULL, `last_name` varchar(16) NOT NULL, `gender` char(1) NOT NULL, `hire_date` date NOT NULL, PRIMARY KEY (`emp_no`)); 解题思路：根据入职时间倒序排序 order by ... DESC ，然后再取一条记录，就是最晚入职的员工。 select * from employees order by hire_date DESC limit 1; 这样做有一个问题， hire_date 是 date 类型，很有可能多条记录中是同一个时间入职的，所以说时间类型还是用时间戳比较精切。 针对这道题目可以使用 MAX() 函数，然后用一个子查询。 select * from employees where hire_date = (select MAX(hire_date) FROM employees); MAX() 先查询出最晚入职的时间，然后再查询出在最晚时间入职的所有员工。 2.

繁琐复杂的执行计划、可能迷了开发人员的眼、导致一条性感又傻X的SQL 在服务器上跑得特欢乐 有介于此、重点抓住几个部分、至于其他的嘛、当然是、非礼勿视咯、、 ㈠ 返回行的数量 Oracle优化器是基于成本的、评估成本的一个主要指标便是查询多少行 一般的、返回值在100W或者大表返回值超过总记录50%、可优化的空间就非常小 标记图为： ㈡ 返回行与逻辑读的比率 经验值是：每行5个以下一致性读(consistent gets + db block gets = 所谓的logical reads)开销是可接受的 标记图为： 每行需要花费7 个逻辑读 ㈢ 聚合查询 这类查询有 2 点需要注意： ① 返回行应是扫描表的行数而不是1 ② 一般的优化技巧：把索引当成瘦表而无需再回表(回表标识为 Table Access By index rowid) 标记图为： ㈣ 预测行的准确度 执行计划里有个列叫：Rows、这是Oracle 预测返回的行、有些时候或许不是特马准备 记得拿该值和真正返回的行比较、如果确实不准确、应该去找原因、比如统计信息、直方图、高水位...等 标记图为： ㈤ 谓词信息 Predicate Information 有2 个取值：filter 和 access、其中、access 一般为索引读或hash join 关注此鸟、最重要的在于、查看是否有发生数据类型转换、这抑制了索引

概述 MySQL中临时表主要有两类，包括外部临时表和内部临时表。 外部临时表是通过语句create temporary table...创建的临时表，临时表只在本会话有效，会话断开后，临时表数据会自动清理。 内部临时表主要有两类，一类是information_schema中临时表，另一类是会话执行查询时，如果执行计划中包含有“Using temporary”时，会产生临时表。 内部临时表与外部临时表的一个区别在于，我们看不到内部临时表的表结构定义文件frm。 而外部临时表的表定义文件frm，一般是以#sql{进程id}_{线程id}_序列号组成，因此不同会话可以创建同名的临时表。 临时表 临时表与普通表的主要区别在于是否在实例，会话，或语句结束后，自动清理数据。 比如，内部临时表，我们在一个查询中，如果要存储中间结果集，而查询结束后，临时表就会自动回收，不会影响用户表结构和数据。 另外就是，不同会话的临时表可以重名，所有多个会话执行查询时，如果要使用临时表，不会有重名的担忧。 5.7引入了临时表空间后，所有临时表都存储在临时表空间(非压缩)中，临时表空间的数据可以复用。 临时表并非只支持Innodb引擎，还支持myisam引擎，memory引擎等。 因此，临时表我们看不到实体(idb文件)，但其实不一定是内存表，也可能存储在临时表空间中。 临时表 VS 内存表

概述 MySQL5.7的发行声明中，官方称之为里程碑式的版本，除了运行速度大幅度提升之外，还添加了之前版本没有的功能，如本文所述的原生JSON数据类型功能。 在此版本之前，MySQL所有的JSON数据类型，全部是使用text等文本类型来实现的，数据的处理只能在应用代码级来实现，十分不方便。 什么是JSON类型 作为DBA，可能会对这个概念稍微有点陌生，但是对于开发者来说，这是一个十分熟悉的事物。 JSON(JavaScript Object Notation, JS 对象简谱) 是一种轻量级的数据交换格式。它基于 ECMAScript (欧洲计算机协会制定的js规范)的一个子集，采用完全独立于编程语言的文本格式来存储和表示数据。简洁和清晰的层次结构使得 JSON 成为理想的数据交换语言。 易于人阅读和编写，同时也易于机器解析和生成，并有效地提升网络传输效率。 MySQL原始JSON类型的优势在哪？ 原生的JSON优势如下： 存储上类似text,可以存非常大的数据。 存储在JSON列中的JSON文档的自动验证 。无效的文档会产生错误。 优化的存储格式。存储在JSON列中的JSON文档将 转换为内部格式，以允许对文档元素进行快速读取访问。 相比于传统形式，不需要遍历所有字符串才能找到数据。 支持索引：通过虚拟列的功能可以对JSON中部分的数据进行索引。 MySQL的JSON类型

常常遇到这样的问题：数据库访问量很大，想要从SQL方面进行优化。往往开发同学会问：能看到哪些SQL执行比较频繁吗？回道：不能哦，只能看到当前正在运行的SQL和慢日志里记录的SQL。 常常遇到这样的问题：数据库访问量很大，想要从SQL方面进行优化。往往开发同学会问：能看到哪些SQL执行比较频繁吗？回道：不能哦，只能看到当前正在运行的SQL和慢日志里记录的SQL。 因为为了性能考虑，一般general log不会开启。slow log可以定位一些有性能问题的sql，而general log会记录所有的SQL。 mysql5.0版本，如果要开启slow log、general log，需要重启，从MySQL5.1.6版开始，general query log和slow query log开始支持写到文件或者数据库表两种方式，并且日志的开启，输出方式的修改，都可以在Global级别动态修改。 root@(none) 09:40:33>select version(); +————+ | version() | +————+ | 5.1.37-log | +————+ 1 row in set (0.02 sec) 设置日志输出方式为文件（如果设置log_output=table的话，则日志结果会记录到名为gengera_log的表中，这表的默认引擎都是CSV）： root@(none)