甜橘子，专注成都网站制作网站设计与营销型网站建设与优化
QQ :532337155
电话：028-86922220
用innodb存储引擎.....既然是很小的数据库...将 innodb_buffer_pool_size 设置为 数据库的大小....这样数据会放在内存中....
创新互联公司坚持“要么做到，要么别承诺”的工作理念，服务领域包括：成都网站建设、网站设计、企业官网、英文网站、手机端网站、网站推广等服务，满足客户于互联网时代的桂平网站设计、移动媒体设计的需求，帮助企业找到有效的互联网解决方案。努力成为您成熟可靠的网络建设合作伙伴！
每个连接到MySQL服务器的线程都需要有自己的缓冲。大概需要立刻分配256K，甚至在线程空闲时 — 它们使用默认的线程堆栈，网络缓存等。事务开始之后，则需要增加更多的空间。运行较小的查询可能仅给指定的线程增加少量的内存消耗，然而如果对数据表做复杂的操作例如扫描、排序或者需要临时表，则需分配大约 read_buffer_size, sort_buffer_size, read_rnd_buffer_size, tmp_table_size 大小的内存空间。不过它们只是在需要的时候才分配，并且在那些操作做完之后就释放了。有的是立刻分配成单独的组块，例如 tmp_table_size 可能高达MySQL所能分配给这个操作的最大内存空间了。注意，这里需要考虑的不只有一点 — 可能会分配多个同一种类型的缓存，例如用来处理子查询。一些特殊的查询的内存使用量可能更大 — 如果在MyISAM表上做成批的插入时需要分配 bulk_insert_buffer_size 大小的内存。执行 ALTER TABLE, OPTIMIZE TABLE, REPAIR TABLE 命令时需要分配 myisam_sort_buffer_size 大小的内存。
For OLTP applications with simple queries memory consumption is often less than 1MB per thread with default buffers, and you really do not need to increase per thread buffers unless you have complex queries. Sorting 10 rows will be as fast with 1MB sort buffer as with 16MB （actually 16MB might be even slower but it is other story）。
只有简单查询OLTP应用的内存消耗经常是使用默认缓冲的每个线程小于1MB，除非需要使用复杂的查询否则无需增加每个线程的缓冲大小。使用1MB的缓冲来对10行记录进行排序和用16MB的缓冲基本是一样快的（实际上16MB可能会更慢，不过这是其他方面的事了）。
Another approach you may take is to come up with amount of memory you want MySQL Server to consume at peak. This can be easily computed by memory needed for OS, File Cache and other applications. For 32bit envinronment you also should keep 32bit limits into account and probably limit “mysqld” size to about 2.5GB （exact number depens on a lot of factors）。 Now you can use “ps aux” to see VSZ - Virtual Memory allocated by MySQL process. You can also look at “Resident Memory” but I find it less helpful as it may down because of swapping - not what you would like to see. Monitor how the value changes so you know memory requirements with current settings and increase/decrease values appropriately.
另外，就是找出MySQL服务器内存消耗的峰值。这很容易就能计算出操作系统所需的内存、文件缓存以及其他应用。在32位环境下，还需要考虑到32位的限制，限制 “mysqld” 的值大约为2.5G（实际上还要考虑到很多其他因素）。现在运行 “ps aux” 命令来查看 VSZ 的值 — MySQL 进程分配的虚拟内存。也可以查看 “Resident Memory” 的值，不过我想它可能没多大用处，因为它会由于交换而变小 — 这并不是你想看到的。监视着内存变化的值，就能知道是需要增加/减少当前的内存值了。
Some may say, Hey we want to have 100% guarantee our server will never run out of memory, no matter which queries or users will decide to run. Unfortunately this is as much close to impossible to be impractical. Here is why:
List of rarely considered MySQL Server Memory Requirements
以下是很少考虑的MySQL服务器内存需求
Thread buffers can be allocated more than once for each thread. Consider for example subqueries - each layer may need its own read_buffer,sort_buffer, tmp_table_size etc每个线程可能会不止一次需要分配缓冲。 考虑到例如子查询 — 每层都需要有自己的 read_buffer,sort_buffer, tmp_table_size 等。Many variabes can be set per connection. So you can't relay on global values if developers may use their local values to run some queries.在每个连接中很多变量都可能需要重新设置。 如果开发者想设定自己的变量值来运行某些查询就不能继续使用全局值。There can be mutiple key caches. Multiple key caches can be created to accomodate query executions可能有多个索引缓存。 为了配合执行查询可能会创建多个索引缓存。Query Parsing and optimization needs memory. This is usually small to be ignored but certain queries can have very large memory requrement for this step, especially specially crafted ones.解析查询和优化都需要内存。 这些内存通常比较小，可以忽略，不过如果是某些查询在这个步骤中则需要大量内存，尤其是那些设计的比较特别的查询。Stored Procedures. Compex stored procedures may require a lot of memory存储过程。 复杂的存储过程可能会需要大量内存。Prepared statements and Cursors. Single connection may have many prepared statements and cursors. Their number finally can be limited but each of them still can have very large memory consumption准备查询语句以及游标。 单次链接可能会有很多的准备好的语句以及游标。它们的数量最后可以限定，但是仍然会消耗大量的内存。Innodb Table Cache. Innodb has its own table cache in which meta data about each table accessed from the start is stored. It is never purged and may be large if you have a lot of tables. It also means user having CREATE TABLE privilege should be able to run MySQL server out of memoryInnodb表缓存。 Innnodb表有自己的缓存，它保存了从一开始访问每个表的元数据。它们从未被清除过，如果有很多Innodb表的话，那么这个量就很大了。这也就意味着拥有 CREATE TABLE 权限的用户就可能把MySQL服务器的内存耗尽。MyISAM buffers. MyISAM may allocate buffer which is large enough to contain largest record in the given table which is held until table is closed.MyISAM缓冲。 MyISAM表可能会分配一个足以装下指定表最大记录的缓冲，而且这个缓冲直到表关闭了才释放。Federated Storage Engine. This may have unbound memory requirements retriving result sets from remove queries.FEDERATED存储引擎。 This may have unbound memory requirements retriving result sets from remove queries.Blobs may require 3x time of memory. This is important if you're deaing with large Blobs （your max_allowed_packet is large） Processing of 256MB of blob may require 768MB of memory.Blobs可能需要3倍的内存。 这在处理很大（max_allowed_packet 的值较大）的Blobs数据时很重要，如果处理256MB的数据可能需要768MB的内存。Storage Engines. In general storage engines may have their own per thread or global memory allocations which are not tuned as buffers. Watch for these especially now with many storage engines being released for MySQL by various parties.存储引擎。 通常情况下，存储引擎会设置自己的每个线程的全局分配内存，它通常不能像缓存一样可以调节。现在应该通过各种方式来特别关注MySQL释放出来的存储引擎。 I do not pretend this to be complete list. On the contrary I'm quite sure I've missed something （drop me a note if you have something to add）。 But the main point is - there are a lot of memory consumers out where and trying to find peak possible usage for each is impractical - so my advice would be measure what you get in practice and how memory consumption reacts to changing various variables. For example you may find out increasing sort_buffer_size from 1MB to 4MB and 1000 max_connections increases peak memory consumption just 30MB not 3000MB as you might have counted.
我想这还不是完成的列表，相反地，我觉得还是漏掉了一些（如果你知道，请给我回复加上）。但主要的原因是 — 找到每次内存消耗峰值是不切实际的，因此我的这些建议可以用来衡量一下你实际修改一些变量值产生的反应。例如，把 sort_buffer_size 从1MB增加到4MB并且在 max_connections 为 1000 的情况下，内存消耗增长峰值并不是你所计算的3000MB而是30MB。
Mysql中的内存分配相关配置参数这些参数可以分成两部分，分别对应MySQL中的两个层次：服务器层和存储引擎层。MySQL服务器相关：
每个连接到MySQL服务器的线程都需要有自己的缓冲，默认为其分配256K。事务开始之后，则需要增加更多的空间。运行较小的查询可能仅给指定的线程增加少量的内存消耗，例如存储查询语句的空间等。但如果对数据表做复杂的操作比较复杂，例如排序则需要使用临时表，此时会分配大约 read_buffer_size，sort_buffer_size，read_rnd_buffer_size，tmp_table_size大小的内存空间。不过它们只是在需要的时候才分配，并且在那些操作做完之后就释放了。read_buffer_size是MySql读入缓冲区大小。对表进行顺序扫描的请求将分配一个读入缓冲区，MySql会为它分配一段内存缓冲区。read_buffer_size变量控制这一缓冲区的大小。如果对表的顺序扫描请求非常频繁，并且你认为频繁扫描进行得太慢，可以通过增加该变量值以及内存缓冲区大小提高其性能。sort_buffer_size是MySql执行排序使用的缓冲大小。如果想要增加ORDER BY的速度，首先看是否可以让MySQL使用索引而不是额外的排序阶段。如果不能，可以尝试增加sort_buffer_size变量的大小。该变量会监测sort_merge_passed, sort_range, sort_rows, sort_scan的状况。通常较小的sort_merge_passed性能越高，但是也与workload的特性有关。read_rnd_buffer_size是MySql的随机读缓冲区大小。当按任意顺序读取行时（例如，按照排序顺序），将分配一个随机读缓存区。进行排序查询时，MySql会首先扫描一遍该缓冲，以避免磁盘搜索，提高查询速度，如果需要排序大量数据，可适当调高该值。但MySql会为每个客户连接发放该缓冲空间，所以应尽量适当设置该值，以避免内存开销过大。
query_cache_size是MySql的查询缓冲大小。（从4.0.1开始，MySQL提供了查询缓冲机制）使用查询缓冲，MySQL将 SELECT语句和查询结果存放在缓冲区中，今后对于同样的SELECT语句（区分大小写），将直接从缓冲区中读取结果。根据MySQL用户手册，使用查询缓冲最多可以达到238%的效率。此外还有每个连接中会使用的一些变量会消耗少量内存。MyISAM引擎相关
key_buffer_size存储了所有index的缓存，一般我们设为16M，通过检查状态值Key_read_requests和 Key_reads，可以知道key_buffer_size设置是否合理。比例key_reads / key_read_requests应该尽可能的低，至少是1:100，1:1000更好（上述状态值可以使用‘key_read%’获得用来显示状态数据）。key_buffer_size只对MyISAM表起作用。即使不使用MyISAM存储引擎，但是内部的临时磁盘表是MyISAM表，故也要使用该值。InnoDB引擎相关
innodb_buffer_pool_size对于InnoDB表来说，作用就相当于key_buffer_size对于MyISAM表的作用一样。InnoDB使用该参数指定大小的内存来缓冲数据和索引。对于单独的MySQL数据库服务器，手册上推荐把该值设置成物理内存的80%。
innodb_additional_mem_pool_size指定InnoDB用来存储数据字典和其他内部数据结构的内存池大小。缺省值是1M。通常不用太大，只要够用就行，应该与表结构的复杂度有关系。如果不够用，MySQL会在错误日志中写入一条警告信息。
innodb_log_buffer_size指定InnoDB用来存储日志数据的缓存大小，如果您的表操作中包含大量并发事务（或大规模事务），并且在事务提交前要求记录日志文件，请尽量调高此项值，以提高日志效率。
查看 /proc/meminfo
Tips：
“大内存页”也称传统大页、大页内存等有助于 Linux 进行虚拟内存的管理，标准的内存页为 4KB，这里使用“大内存页”最大可以定义 1GB 的页面大小，在系统启动期间可以使用“大内存页”为应用程序预留一部分内存，这部分内存被占用且永远不会被交换出内存，它会一直保留在那里，直到改变配置。（详细介绍请看下面链接官方解释）
那么这么大页内存是分配给谁的呢？
查询一下：
shell /proc/sys/vm/hugetlb_shm_group
27
shell id 27
uid=27(mysql) gid=27(mysql) groups=27(mysql)
hugetlb_shm_group 文件里填的是指定大页内存使用的用户组 id，这里查看到是 MySQL 组 id，那既然是给 MySQL 的为什么 free 等于 total，并且 mysql 还只有 20 多 G 实际使用内存呢？
原来在 MySQL 中还有专门启用大内存页的参数，在 MySQL 大内存页称为 large page。
查看 MySQL 配置文件
发现配置文件中确实有 large-page 配置，但出于禁用状态。
后与业务确认，很早之前确实启用过 mysql 的 large page，不过后面禁用了。排查到这基本就有了结论。
结论
这套环境之前开启了 20000 的大内存页，每页大小为 2MB，占用了 40G 内存空间，给 MySQL 使用，并且 MySQL 开启了 large page，但后来不使用的时候，只关闭了 MySQL 端的 large page 参数，但没有实际更改主机的关于大内存页的配置，所以导致，实际上主机上的还存在 20000 的大内存页，并且没在使用，这一部分长期空闲，并且其他程序不能使用。
所以 MySQL 在使用 20G 内存左右，整个主机内存就饱和了，然后在部分条件下，就触发了 OOM，导致 mysqld 被 kill，但主机上又有 mysqld_safe 守护程序，所以又再次给拉起来，就看到了文章初的偶尔连接不上的现象。
数据库里只存对应的照片地址啦····
比如 upload/images/xxx.jpg
JSP页面就这样显示咯
%
String imgUrl = “upload/images/xxx.jpg”;//这个地址是你实际从数据库里取出来的,，如果怕照片显示不出来，加上绝对路径request.getContextPath()+"/"+imgUrl %
img src="%=imgUrl %" alt="images"/
生产环境中，MySQL 不经意间吃掉全部的内容，然后开始吃掉 SWAP，性能一降再降，怎么办？
可以从下面三点查看原因：
MySQL 使用内存，有两个途径。
永久占用的内容
比如全局缓冲区（Global Buffer）类别，是在服务器启动期间从操作系统获得的，不会释放到任何一个别的进程。
动态请求的内存
线程缓冲区由MySQL使用，它是在处理新查询时从操作系统请求的内存。在执行查询之后，该内存被释放回操作系统。
这意味着 MySQL 的内存使用，是 全局缓冲区 加上 线程缓冲区 以及 允许的最大连接数 。
对于专用数据库服务器，该值需要保持在服务器内存的90%以下。在共享服务器的情况下，它应该保持在服务器内存的50%以下。
检查一下 MySQL 设置，有助于确定内存使用情况，从而为 MySQL 分配合适的值。
一个近似的公式：
当网站受到攻击时，有可能在短时间内建立异常高的连接数量。MySQL 中的 PROCESSLIST 可用于检测顶级用户并阻止对滥用连接的访问。
找出查询需要很长时间才能执行的语句，因为这些查询需要进一步优化服务器才能更好地执行，可以通过服务器查询日志进行识别。由于查询速度慢，导致磁盘读取较多，导致内存和CPU使用率较高，影响服务器性能。
最后，到了加内存条的时候了。虽然在优化数据库设置之后，服务器会不断地路由到使用交换内存，但也必须增加内存。俗话说：“巧妇难为无米之炊”，就是这个意思。
上面说的这些方向，大家可以在实际操作中验证体会，希望大家在数据库优化的路上，麻溜顺畅，砥砺前行。