Mysqlslap是从5.1.4版开始的一个MySQL官方提供的压力测试工具。通过模拟多个并发客户端访问MySQL来执行压力测试，同时详细的提供了“高负荷攻击MySQL”的数据性能报告。并且能很好的对比多个存储引擎在相同环境下的并发压力性能差别。
创新互联建站专注于平凉网站建设服务及定制，我们拥有丰富的企业做网站经验。 热诚为您提供平凉营销型网站建设，平凉网站制作、平凉网页设计、平凉网站官网定制、小程序开发服务，打造平凉网络公司原创品牌,更为您提供平凉网站排名全网营销落地服务。
它的使用语法如下：
shell/usr/local/mysql/bin/mysqlslap [options]
常用参数【options】详细介绍：
--concurrency代表并发数量，多个可以用逗号隔开。例如：--concurrency=50,200,500
--engines代表要测试的引擎，可以有多个，用分隔符隔开。例如：--engines=myisam,innodb,memory
--iterations代表要在不同并发环境下，各自运行测试多少次。
--auto-generate-sql 代表用mysqlslap工具自己生成的SQL脚本来测试并发压力。
--auto-generate-sql-add-auto-increment 代表对生成的表自动添加auto_increment列，从5.1.18版本开始，
--auto-generate-sql-load-type 代表要测试的环境是读操作还是写操作还是两者混合的（read,write,update,mixed）
--number-of-queries 代表总共要运行多少条查询。
--debug-info 代表要额外输出CPU以及内存的相关信息。
--number-int-cols 代表示例表中的INTEGER类型的属性有几个。
--number-char-cols代表示例表中的vachar类型的属性有几个。
--create-schema 代表自定义的测试库名称。
--query 代表自定义的测试SQL脚本。
说明：
测试的过程需要生成测试表，插入测试数据，这个mysqlslap可以自动生成，默认生成一个mysqlslap的schema，如果已经存在则先删除。可以用-only-print来打印实际的测试过程，整个测试完成后不会在数据库中留下痕迹。
实验步骤：
练习一：
单线程测试。测试做了什么。
./bin/mysqlslap -a -uroot -p111111
多线程测试。使用--concurrency来模拟并发连接。
./bin/mysqlslap -a -c 100 -uroot -p111111
迭代测试。用于需要多次执行测试得到平均值。
./bin/mysqlslap -a -i 10 -uroot -p111111
练习二：
./bin/mysqlslap -auto-generate-sql-add-autoincrement -a -uroot -p111111
./bin/mysqlslap -a -auto-generate-sql-load-type=read -uroot -p111111
./bin/mysqlslap -a -auto-generate-secondary-indexes=3 -uroot -p111111
./bin/mysqlslap -a -auto-generate-sql-write-number=1000 -uroot -p111111
./bin/mysqlslap --create-schema world -q "select count(*) from City" -uroot -p111111
./bin/mysqlslap -a -e innodb -uroot -p111111
./bin/mysqlslap -a --number-of-queries=10 -uroot -p111111
练习三：
执行一次测试，分别50和100个并发，执行1000次总查询：
./bin/mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --debug-info -uroot -p111111
50和100个并发分别得到一次测试结果(Benchmark)，并发数越多，执行完所有查询的时间越长。为了准确起见，可以多迭代测试几次:
./bin/mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --iterations=5 --debug-info -uroot -p111111
测试同时不同的存储引擎的性能进行对比：
./bin/mysqlslap -a --concurrency=50,100 --number-of-queries 1000 --iterations=5 --engine=myisam,innodb --debug-info -uroot -p111111
一、Memcached简介
memcached
常被用来加速应用程序的处理，在这里，我们将着重于介绍将它部署于应用程序和环境中的最佳实践。这包括应该存储或不应存储哪些、如何处理数据的灵活分布以
及如何调节用来更新 memcached 和所存储数据的方法。我们还将介绍对高可用性的解决方案的支持，比如 IBM WebSphere® eXtreme
Scale。
所有的应用程序，特别是很多 web
应用程序都需要优化它们访问客户机和将信息返回至客户机的速度。可是，通常，返回的都是相同的信息。从数据源(数据库或文件系统)加载数据十分低效，若是每次想要访问该信息时都运行相同的查询，就尤显低效。
虽然很多 web 服务器都可被配置成使用缓存发回信息，但那与大多数应用程序的动态特性无法相适。而这正是 memcached
的用武之地。它提供了一个通用的内存存储器，可保存任何东西，包括本地语言的对象，这就让您可以存储各种各样的信息并可以从诸多的应用程序和环境访问这些信息。
二、基础知识
memcached 是一个开源项目，旨在利用多个服务器内的多余 RAM
来充当一个可存放经常被访问信息的内存缓存。这里的关键是使用了术语缓存：memcached 为加载自他处的信息提供的是内存中的暂时存储。
比如，考虑这样一个典型的基于 web 的应用程序。即便是一个动态网站可能也会有一些组件或信息常量是贯穿页面整个生命周期的。在一个博客站点内，针对单个
blog post
的类别列表不大可能在页面查看间经常性地变更。每次都通过一个对数据库的查询加载此信息相对比较昂贵，特别是在数据没有更改的情况下，就更是如此。从图 1
可以看到一个博客站点内可被缓存的页面分区。
图1.一个典型的博客页面内的可缓存元素
将这种结构放在 blog 站点的其他元素，poster 信息、注释 — 设置 blog post 本身 —
进行推断，可以看出为了显示主页的内容很可能需要发生 10-20 次数据库查询和格式化。
每天对数百甚至数千的的页面查看重复此过程，那么您的服务器和应用程序执行的查询要远远多于为了显示页面内容所需执行的查询。
通过使用 memcached，可以将加载自数据库的格式化信息存储为一种可直接用在 Web 页面上的格式。并且由于信息是从 RAM
而不是通过数据库和其他处理从磁盘加载的，所以对信息的访问几乎是瞬时的。
再强调一下，memcached 是一个用来存储常用信息的缓存，有了它，您便无需从缓慢的资源，比如磁盘或数据库，加载并处理信息了。
对 memcached 的接口是通过网络连接提供的。这意味着您可以在多个客户机间共享单个的 memcached
服务器(或多个服务器，如本文稍后所示的)。这个网络接口非常迅速，并且为了改善性能，服务器会故意不支持身份验证或安全性通信。但这不应限制部署选项。
memcached 服务器应该存在于您网络的内部。网络接口的实用性以及可以部署多个 memcached 实例的简便性让您可以使用多个机器上的多余 RAM
来提高您缓存的整体大小。
三、存储方法
memcached 的存储方法是一个简单的键/值对，类似于很多语言内的散列或关联数组。通过提供键和值来将信息存储到 memcached
内，通过按特定的键请求信息来恢复信息。
信息会无限期地保留在缓存内，除非发生如下的情况：
为缓存分配的内存耗尽 — 在这种情况下，memcached 使用
LRU(最近最少使用)方法从此缓存删除条目。最近未曾使用的条目会从此缓存中先删除，最旧的最先访问。
条目被明确删除 — 总是可以从此缓存内删除条目。
条目过期失效 — 各条目均有一个有效的期限以便针对此键存储的信息在过于陈旧时可从缓存中清除这些条目。
上述这些情况可以与您应用程序的逻辑综合使用以便确保缓存内的信息是最新的。有了这些基础知识后，让我们来看看在应用程序内如何能最好地利用
memcached。
四、何时使用memcached?
在使用 memcached 改进应用程序性能时，可以对一些关键的过程和步骤进行修改。
在加载信息时，典型的场景如图 2 所示。
图2.加载要显示的信息的典型顺序
一般而言，这些步骤是：
执行一个或多个查询来从数据库加载信息
格式化适合于显示(或进一步处理)的信息
使用或显示格式化了的数据
在使用 memcached 时，为配合这个缓存，可对应用程序的逻辑进行稍许修改：
尽量从缓存加载信息
如果存在，使用信息的被缓存版本
如果它不存在：
执行一个或多个查询来从数据库加载信息
格式化适合于显示或进一步处理的信息
将信息存储到缓存内
使用格式化了的数据
图 3 是对这些步骤的总结。
图3.在使用memcached时加载适合于显示的信息
数据加载成为了至多三个步骤的一个过程，从缓存加载数据或从数据库(视情况而定)加载数据并存储在缓存内。
当这个过程首次发生时，数据将正常地从数据库或其他数据源加载，然后再存储到 memcached 内。当下一次访问此信息时，它就会从 memcached
拉出，而不是从数据库加载，节省了时间和 CPU 循环。
问题的另一个方面是要确保如果更改了要存储在 memcached 内的信息，在更新后端信息的同时还要更新 memcached 的版本。这会让图 4
内所示的这个典型顺序发生稍许变化，如 图 5 所示。
图4.在一个典型的应用程序内更新或存储数据
图 5 显示了使用 memcached 后发生了变化的流程。
图5.在使用memcached时更新或存储数据
比如，仍以博客站点为例，在博客系统更新数据库内的类别列表时，更新应该遵循如下顺序：
更新数据库内的类别列表
格式化信息
将信息存储到 memcached 内
将信息返回至客户机
memcached 内的存储操作是原子的，所以信息的更新不会让客户机只获得部分数据;它们获得的或者是老版本，或者是新版本。
对于大多数应用程序，这两个操作是您惟一需要注意的。在访问他人使用的数据时，它会自动被添加到这个缓存内，而且如果对该数据进行了更改，此缓存内也会自动进行更新。
五、键、名称空间和值
memcached
另一个需要重点考虑的因素是如何组织和命名存储在缓存内的这些数据。从之前博客站点的例子中，不难看出需要使用一种一致的命名结构以便您能加载博客类别、历史和其他信息，然后再在加载信息(并更新缓存)时或者在更新数据(同样也要更新缓存)时使用。
使用的何种具体的命名系统特定于应用程序，但通常可以使用一种与现有应用程序类似的结构，并且这种结构很可能基于某种惟一识别符。当从数据库拉出信息或在整理信息集时，就会发生这种情况。
以 blog post 为例，可以在一个具有键 category-list 的项中存储类别列表。与此 post ID 对应的单个 post，比如
blogpost-29 相关的值都可以使用，而该项的注释则可以存储在 blogcomments-29内，其中 29 就是这个 blog post 的
ID。这样一来， 您就可以将各种各样的信息存储在缓存内，使用不同的前缀来标识这些信息。
memcached 键/值存储的简便性(以及安全性的缺乏)意味着如果您想要在使用同一个 memcached
服务器的同时支持多个应用程序，那么就可以考虑使用其他格式的量词来标识数据属于某种特定的应用程序。比如，可以添加像 blogapp:blogpost-29
这样的应用程序前缀。这些键是没有格式的，所以可以使用任何字符串作为键的名称。
在存储值的方面，应该确保存储在缓存内的信息适合于您的应用程序。比如，对于这个博客系统，您可能想要存储被博客应用程序使用的对象以便格式化博客信息，而不是原始的
HTML。如果同一个基础结构用在应用程序内的多个地方，这一点更具实用性。
大多数语言的接口，包括 Java™、Perl、PHP 等，都能串行化语言对象以便存储在 memcached
内。这就让您可以存储并随后从内存存储恢复全部对象，而不是在您的应用程序内手动重构它们。
很多对象，或它们使用的结构，都基于某种散列或数组结构。对于跨语言的环境，比如在 JSP 环境和 JavaScript
环境间共享相同信息，可以使用一种架构中立的格式，比如 JavaScript Object Notation (JSON) 甚或 XML。
六、填充并使用memcached
作为一种开源产品以及一种最初开发用来工作于现有开源环境内的产品，memcached 受大量环境和平台支持。与 memcached
服务器通信的接口有很多，并常常具有针对所有语言的多个实现。参见参考资料 以获得常用的库和工具箱。
要列出所有受支持的接口和环境不太可能，但它们均支持 memcached 协议提供的基础
API。这些描述已经被简化并应用在不同语言的上下文内，在这些语言中，使用不同的值可指示错误。主要的函数有：
get(key) — 从存储了特定键的 memcached 获得信息。 如果键不存在，就返回错误。
set(key, value [, expiry]) —
使用缓存内的标识符键存储这个特定的值。如果键已经存在，那么它就会被更新。期满时间的单位为秒，并且如果值小于 30 天
(30*24*60*60)，那么就用作相对时间，如果值大于 30 天，那么就用作绝对时间 (epoch)。
add(key, value [, expiry]) —
如果键不存在就将这个键添加到缓存内，如果键已经存在就返回错误。如果您想要显式地添加一个新键而又不会因它已经存在而更新它，那么这个函数将十分有用。
replace(key, value [, expiry]) — 更新此特定键的值，如果键不存在就返回一个错误。
delete(key [, time]) —
从缓存中删除此键/值对。如果您提供一个时间，那么添加具有此键的一个新值就会被阻塞这个特定的时期。超时让您可以确保此值总是可以重新读取自您的数据中心。
incr(key [, value]) — 为特定的键增 1 或特定的值。只适用于数值。
decr(key [, value]) — 为特定的键减 1 或特定的值，只适用于数值。
flush_all — 让缓存内的所有当前条目无效(或到期失效)。
比如，在 Perl 内，基本 set 操作可以如清单 1 所示的那样处理。
清单 1. Perl 内的基本 set 操作
use Cache::Memcached;
my $cache = new Cache::Memcached {
'servers' = [
'localhost:11211',
],
};
$cache-set('mykey', 'myvalue');
Ruby 内的相同的基本操作如清单 2 所示。
清单 2. Ruby 内的基本 set 操作
require 'memcache'
memc = MemCache::new '192.168.0.100:11211'
memc["mykey"] = "myvalue"
在两个例子中可以看到相同的基本结构：设置 memcached 服务器，然后分配或设置值。其他的接口也可用，包括适合于 Java
技术的那些接口，让您可以在 WebSphere 应用程序内使用 memcached。memcached 接口类允许将 Java 对象直接序列化到
memcached 以便于存储和加载复杂的结构。当在像 WebSphere 这样的环境内进行部署时，有两个事情非常重要：服务的弹性(在 memcached
不可用时如何做)以及如何提高缓存存储量来改进在使用多个应用程序服务器或在使用像 WebSphere eXtreme Scale
这样的环境时的性能。我们接下来就来看看这两个问题。
七、弹性和可用性
有关 memcached
最常见的一个问题是：“若缓存不可用了，会发生什么情况呢?”正如之前章节中明示的，缓存内的信息不应该成为信息的的惟一资源。必须要能够从其他位置加载存储在缓存内的数据。
虽然，无法从缓存访问信息将会减缓应用程序的性能，但它不应该阻止应用程序的运转。可能会发生这样几个场景：
如果 memcached 服务宕掉，应用程序应该回退到从原始数据源加载信息并对信息进行显示所需的格式化。此应用程序还应继续尝试在 memcached
内加载和存储信息。
一旦 memcached
服务器恢复可用，应用程序就应该自动尝试存储数据。没有必要强制重载已缓存了的数据，可以使用标准的访问来用信息加载和填充缓存。最终，缓存将会被最常用的数据重新填充。
再次重申，memcached 是信息的缓存但并非惟一的数据源。memcached 服务器不可用不应该是应用程序的终结，虽然这意味着在
memcached 服务器恢复正常之前性能会有所降低。实际上，memcached
服务器相对简单，并且虽然不是绝对无故障的，但它的简单性的结果就是它很少会出错。
八、分配缓存
memcached 服务器只是网络上针对一些键存储值的一个缓存。如果有多台机器，那么很自然地会想要在所有多余机器上设置一个 memcached
的实例来提供一个超大的联网 RAM 缓存存储。
有了这个想法后，还有一种想当然是需要使用某种分配或复制机制来在机器之间复制键/值对。这种方式的问题是如果这么做反而会减少可用的 RAM
缓存，而不是增加。如图 6 所示，可以看出这里有三个应用程序服务器，每个服务器都可以访问一个 memcached 实例。
图6.多重memcached实例的不正确使用
尽管每个 memcached 实例都是 1 GB 的大小(产生 3 GB 的 RAM 缓存)，但如果每个应用程序服务器只有其自己的缓存(或者在
memcached 之间存在着数据的复制)，那么整个安装也仍只能有 1 GB 的缓存在每个实例间复制。
由于 memcached 通过一个网络接口提供信息，因此单个的客户机可以从它所能访问的任何一个 memcached
实例访问数据。如果数据没有跨每个实例被复制，那么最终在每个应用程序服务器上，就可以有 3 GB 的 RAM 缓存可用，如图 7 所示。
图7.多重memcached实例的正确使用
这个方法的问题是选择哪个服务器来储存键/值对，以及当想要重新获得一个值时，如何决定要与哪个 memcached
服务器对话。问题的解决方案就是忽略复杂的东西，比如查找表，或是寄望 memcached 服务器来为您处理这个过程。而 memcached
客户机则必须要力求简单。
memcached 客户机不必决定此信息，它只需对在存储信息时指定的键使用一个简单的散列算法。当想要从一列 memcached
服务器存储或获取信息时，memcached 客户机就会用一个一致的散列算法从这个键获取一个数值。举个例子，键 mykey 被转换成数值 23875
。是保存还是获取信息无关紧要，这个键将总是被用作惟一标识符来从 memcached 服务器加载，因此在本例中，“mykey” 散列转化后对应的值总是
23875。
如果有两个服务器，那么 memcached 客户机将对这个数值进行一个简单的运算(例如，系数)来决定它应将此值存储在第一个还是第二个配置了的
memcached 实例上。
当存储一个值时，客户机会从这个键确定出散列值以及它原来存储在哪个服务器上。当获取一个值时，客户机会从这个键确定出相同的散列值并会选择相同的服务器来获取信息。
如果在每个应用程序服务器上使用的是相同的服务器列表(并且顺序相同)，那么当需要保存或检索同一个键时，每个应用程序服务器都将选择同一个
服务器。现在，在这个例子中，有 3GB 的 memcached 空间可以共享，而不是同一个 1 GB
的空间的复制，这就带来了更多的可用缓存，并很有可能会提高有多个用户情况下的应用程序的性能。
九、如何能不使用memcached?
尽管 memcached 很简单，但 memcached 实例有时候还是会被不正确地使用。
memcached不是一个数据库
最常见的 memcached 误用就是把它用作一个数据存储，而不是一个缓存。memcached
的首要目的就是加快数据的响应时间，否则数据从其他数据源构建或恢复需要很长时间。一个典型的例子就是从一个数据库中恢复信息，特别是在信息显示给用户前
需要对信息进行格式化或处理的时候。Memcached 被设计用来将信息存储在内存中以避免每次在数据需要恢复时重复执行相同的任务。
切不可将 memcached 用作运行应用程序所需信息的惟一信息源;数据应总是可以从其他信息源获取。此外，要记住 memcached
只是一个键/值的存储。不能在数据上执行查询，或者对内容进行迭代来提取信息。应该使用它来存储数据块或对象以备批量使用。
不要缓存数据库行或文件
虽然可以使用 memcached
存储加载自数据库的数据行，但这实际上是查询缓存，并且大多数数据库都提供各自的查询缓存的机制。其他的对象，比如文件系统的图像或文件的情况与此相同。很多应用程序和
web 服务器针对此类工作已经有了一些很好的解决方案。
如果在加载和格式化后，使用它来存储全部信息块，就可以从 memcached
获得更多的实用工具和性能上的改善。仍以我们的博客站点为例，存储信息的最佳点是在将博客类别格式化为对象，甚至是在格式化成 HTML 后。博客页面的构造可通过从
memcached 加载各个组件(比如 blog post、category list、post history 等)并将完成的 HTML
写回至客户机实现。
memcached并不安全
为了确保最佳性能，memcached 并未提供任何形式的安全性，没有身份验证，也没有加密。这意味着对 memcached
服务器的访问应该这么处理：一是通过将它们放到应用程序部署环境相同的私有侧，二是如果安全性是必须的，那么就使用 UNIX® socket
并只允许当前主机上的应用程序访问此 memcached 服务器。
这多少牺牲了一些灵活性和弹性，以及跨网络上的多台机器共享 RAM 缓存的能力，但这是在目前的情况下确保 memcached
数据安全性的惟一一种解决方案。
十、不要限制自己
除了不应该使用 memcached 实例的情况外，memcached 的灵活性不应忽视。由于 memcached
与应用程序处于相同的架构水平，所以很容易集成并连接到它。并且更改应用程序以便利用 memcached 也并不复杂。此外，由于 memcached
只是一个缓存，所以在出现问题时它不会停止应用程序的执行。如果使用正确的话，它所做的是减轻其余服务器基础设施的负载(减少对数据库和数据源的读操
作)，这意味着无需更多的硬件就可以支持更多的客户机。
但请记住，它仅仅是个缓存!
结束语
在本文中，我们了解了 memcached 以及如何最佳地使用它。我们看到了信息如何存储、如何选择合理的键以及如何选择要存储的信息。我们还讨论了所有
memcached 用户都要遇到的一些关键的部署问题，包括多服务器的使用、当 memcached 实例消亡时该怎么做，以及(也许最为重要的)在哪些情况下不能使用
memcached。
作为一种开源的应用程序并且是目的简单而直白的应用程序，memcached 的功能和实用性均来自于这种简单性。通过为信息提供巨大的 RAM
存储空间、让它在网络上可用，然后再让它可通过各种不同的接口和语言访问到，memcached 可被集成到多种多样的安装和环境中。
肯定影响的。
常见查询慢的原因常见的话会有如下几种：
1、没有索引或没有用到索引。
PS：索引用来快速地寻找那些具有特定值的记录，所有MySQL索引都以B-树的形式保存。如果没有索引，执行查询时MySQL必须从第一个记录开始扫描整个表 的所有记录，直至找到符合要求的记录。表里面的记录数量越多，这个操作的代价就越高。如果作为搜索条件的列上已经创建了索引，MySQL无需扫描任何记录 即可迅速得到目标记录所在的位置。如果表有1000个记录，通过索引查找记录至少要比顺序扫描记录快100倍。
索引类型：
普通索引：这是最基本的索引类型，没唯一性之类的限制。
唯一性索引：和普通索引基本相同，但所有的索引列只能出现一次，保持唯一性。
主键：主键是一种唯一索引，但必须指定为"PRIMARY KEY"。
全文索引：MYSQL从3.23.23开始支持全文索引和全文检索。在MYSQL中，全文索引的索引类型为FULLTEXT。全文索引可以在VARCHAR或者TEXT类型的列上创建。
2、IO吞吐量小形成了瓶颈。
PS：这是从系统层来分析MYSQL是比较耗IO的。一般数据库监控也是比较关注IO。
监控命令：$iostat -d -k 1 10
参数 -d 表示，显示设备（磁盘）使用状态；-k某些使用block为单位的列强制使用Kilobytes为单位；1 10表示，数据显示每隔1秒刷新一次，共显示10次。
3、内存不足
监控内存使用：vmstat [-n] [延时[次数]]
Memory
swpd: 切换到交换内存上的内存(默认以KB为单位)
• 如果 swpd 的值不为0，或者还比较大，比如超过100M了，但是si, so 的值长期为0，这种情况我们可以不用担心，不会影响系统性能。
free: 空闲的物理内存
buff: 作为buffer cache的内存，对块设备的读写进行缓冲
cache: 作为page cache的内存, 文件系统的cache• 如果 cache 的值大的时候，说明cache住的文件数多，如果频繁访问到的文件都能被cache住，那么磁盘的读IO bi 会非常小。
4、网络速度慢
ping IP -t 查看是否有丢包。
5、一次查询的数据量过大。
比如没有分页查询，一次提取上万条记录。数据库有可能卡死。
6、出现死锁
所谓死锁: 是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去.
Show innodb status检查引擎状态 ,可以看到哪些语句产生死锁。
执行show processlist找到死锁线程号.然后Kill processNo
7、返回了不必要的行或列
一般查询SQL语句一定要将字段明确指定。而不要使用*进行查询
8、注意UNion和UNion all 的区别。UNION all好
UNION在进行表链接后会筛选掉重复的记录，所以在表链接后会对所产生的结果集进行排序运算，删除重复的记录再返回结果。所以union all的效率肯定要高！
MYSQL列中的数据查询命令：
SELECT *
FROM task_detatils
WHERE FIND_IN_SET( ‘1’, responsible_user)
命令的含义：将含有1的responsible_user列数据全部搜索出来。
采用的是find函数：查找一定范围内元素的个数。查找[first,last)范围内，与toval等价的第一个元素，返回一个迭代器。如果没有这个元素，将返回last。
扩展资料：
其他的查询命令：
在命令后键入搜索的模式，再键入要搜索的文件。其中，文件名列表中也可以使用特殊字符，如“*”等，用来生成文件名列表。
如果想在搜索的模式中包含有空格的字符串，可以用单引号把要搜索的模式括起来，用来表明搜索的模式是由包含空格的字符串组成。
否则，Shell将把空格认为是命令行参数的定界符，而grep命令将把搜索模式中的单词解释为文件名列表中的一部分。在下面的例子中，grep命令在文件example中搜索模式“text file”。
用户可以在命令行上用Shell特殊字符来生成将要搜索的文件名列表。在下面的例子中，特殊字符“*”用来生成一个文件名列表，该列表包含当前目录下所有的文件。该命令将搜索出当前目录下所有文件中与模式匹配的行。
参考资料来源：百度百科-Linux文件内容查询命令
参考资料来源：百度百科-find函数
问题
我们有一个 SQL，用于找到没有主键 / 唯一键的表，但是在 MySQL 5.7 上运行特别慢，怎么办？
实验
我们搭建一个 MySQL 5.7 的环境，此处省略搭建步骤。
写个简单的脚本，制造一批带主键和不带主键的表：
执行一下脚本：
现在执行以下 SQL 看看效果：
...
执行了 16.80s，感觉是非常慢了。
现在用一下 DBA 三板斧，看看执行计划：
感觉有点惨，由于 information_schema.columns 是元数据表，没有必要的统计信息。
那我们来 show warnings 看看 MySQL 改写后的 SQL：
我们格式化一下 SQL：
可以看到 MySQL 将
select from A where A.x not in (select x from B) //非关联子查询
转换成了
select from A where not exists (select 1 from B where B.x = a.x) //关联子查询
如果我们自己是 MySQL，在执行非关联子查询时，可以使用很简单的策略：
select from A where A.x not in (select x from B where ...) //非关联子查询:1. 扫描 B 表中的所有记录，找到满足条件的记录，存放在临时表 C 中，建好索引2. 扫描 A 表中的记录，与临时表 C 中的记录进行比对，直接在索引里比对，
而关联子查询就需要循环迭代：
select from A where not exists (select 1 from B where B.x = a.x and ...) //关联子查询扫描 A 表的每一条记录 rA： 扫描 B 表，找到其中的第一条满足 rA 条件的记录。
显然，关联子查询的扫描成本会高于非关联子查询。
我们希望 MySQL 能先"缓存"子查询的结果（缓存这一步叫物化，MATERIALIZATION），但MySQL 认为不缓存更快，我们就需要给予 MySQL 一定指导。
...
可以看到执行时间变成了 0.67s。
整理
我们诊断的关键点如下：
\1. 对于 information_schema 中的元数据表，执行计划不能提供有效信息。
\2. 通过查看 MySQL 改写后的 SQL，我们猜测了优化器发生了误判。
\3. 我们增加了 hint，指导 MySQL 正确进行优化判断。
但目前我们的实验仅限于猜测，猜中了万事大吉，猜不中就无法做出好的诊断。
Laravel框架中的DB类让我们可以方便的进行数据库操作，比如常见的query查询：
DB::query('SELECT * FROM users');
Larvel还提供了类似CI框架中Active Record的Fluent Query Builder ： DB::table('user')-where('id','=','1')-get();
虽然从操作上和普通查询相差不大，但是需要注意到是Laravel的查询结果和原生查询不同。
简单建立一个contents表测试下，表里有content字段，我们查询一下：
$content = DB::table('contents')-where('id','=','1')-get();
最后打印一下$content变量看看有什么不同：
array(1)
{
[0]= object(stdClass)#31 (1) {
["content"]= string(24) "这是一个测试～～" }
}
从上面可以知道查询的结果是一个包含对象的数组，因此我们要取得content值就必须先迭代：
foreach($contents as $content)
{ echo $content-content;
}
总体来说Laravel的数据库操作很容易上手。
