配置你的mysql配置文件：主要是配置[mysqld]后面的内容。
　　1，优化远程连接速度。
　　在[mysqld]下面添加skip-name-resolve
　　skip-name-resolve
　　选项能禁用DNS解析，连接速度会快很多。不过，这样的话不能在MySQL的授权表中使用主机名了而只能用ip格式。
　　2，设置连接数，mysql默认的连接数是100，太少了。
　　[mysqld]下面添加
　　max_connections=512
　　3，开启缓存机制
　　skip-locking#取消文件系统的外部锁
　　key_buffer = 512M#索引缓存，根据内存大小而定，如果是独立的db服务器，可以设置高达80%的内存总量
　　#连接排队列表总数
　　back_log = 200
　　max_allowed_packet = 2M
　　#打开表缓存总数，可以避免频繁的打开数据表产生的开销
　　table_cache = 512
　　#每个线程排序所需的缓冲
　　sort_buffer_size = 4M
　　#MyISAM表发生变化时重新排序所需的缓冲
　　myisam_sort_buffer_size = 64M
　　#缓存可重用的线程数
　　thread_cache = 128
　　#查询结果缓存
　　query_cache_size = 128M
　　#设置超时时间，能避免长连接
　　wait_timeout=60
　　#大并发线程数，cpu数量*2
　　thread_concurrency = 4
　　#记录慢查询，然后对慢查询一一优化
　　log_output=FILE # also can be FILE，TABLE or TABLE or NONE
　　slow-query-log=1
　　slow_query_log_file=log-slow-queries.log
　　long_query_time = 1
　　4，安装mytop监控mysql
　　apt-get install mytop
　　执行命令mytop可以看到mysql的运行状态。
　　以下内容为转载的网上的文章，对mysql的配置和调试做了很详细的讲解：
　　关于 MySQL 调优
　　有3种方法可以加快 MySQL 服务器的运行速度，效率从低到高依次为：
　　替换有问题的硬件， 对 MySQL 进程的设置进行调优，对查询进行优化。
　　替换有问题的硬件通常是我们的第一考虑，主要原因是数据库会占用大量资源。不过这种解决方案也于此了。实际上，您通常可以让中央处理器(CPU)或磁盘速度加倍，也可以让内存增大4到8倍。
　　第二种方法是对 MySQL 服务器(也称为 mysqld)进行调优。对这个进程进行调优意味着适当地分配内存，并让 mysqld 了解将会承受何种类型的负载。加快磁盘运行速度不如减少所需的磁盘访问次数。类似地，确保 MySQL 进程正确操作意味着它花费在服务查询上的时间要多于花费在处理后台任务(如处理临时磁盘表或打开和关闭文件)上的时间。对 mysqld 进行调优是本文的重点。
　　好的方法是确保查询已经进行了优化。这意味着对表应用了适当的索引，查询是按照可以充分利用 MySQL 功能的方式来编写的。尽管本文并没有包含查询调优方面的内容(很多著作中已经针对这个主题进行了探讨)，不过它会配置 mysqld 来报告可能需要进行调优的查询。
　　虽然已经为这些任务指派了次序，但是仍然要注意硬件和 mysqld 的设置以利于适当地调优查询。机器速度慢也罢了，我曾经见过速度很快的机器在运行设计良好的查询时由于负载过重而失败，因为 mysqld 被大量繁忙的工作所占用而不能服务查询。
　　记录慢速查询
　　在一个 SQL 服务器中，数据表都是保存在磁盘上的。索引为服务器提供了一种在表中查找特定数据行的方法，而不用搜索整个表。当必须要搜索整个表时，称为表扫描。通常来说，您可能只希望获得表中数据的一个子集，因此全表扫描会浪费大量的磁盘 I/O，因此也会浪费大量时间。当必须对数据进行连接时，这个问题更加复杂了，因为必须要对连接两端的多行数据进行比较。
　　当然，表扫描并不总是会带来问题;有时读取整个表反而会比从中挑选出一部分数据更加有效(服务器进程中查询规划器用来作出这些决定)。如果索引的使用效率很低，或者根本不能使用索引，则会减慢查询速度，而且随着服务器上的负载和表大小的增加，这个问题会变得更加显著。执行时间超过给定时间范围的查询称为慢速查询。
　　您可以配置 mysqld 将这些慢速查询记录到适当命名的慢速查询日志中。管理员然后会查看这个日志来帮助他们确定应用程序中有哪些部分需要进一步调查。清单 1 给出了要启用慢速查询日志需要在 my.cnf 中所做的配置。
　　清单 1. 启用 MySQL 慢速查询日志
　　[mysqld]; enable the slow query log， default 10 secondslog-slow-queries; log queries taking longer than 5 secondslong_query_time = 5; log queries that don't use indexes even if they take less than long_query_time; MySQL 4.1 and newer onlylog-queries-not-using-indexes
　　这三个设置一起使用，可以记录执行时间超过 5 秒和没有使用索引的查询。请注意有关 log-queries-not-using-indexes 的警告：您必须使用 MySQL 4.1 或更高版本。慢速查询日志都保存在 MySQL 数据目录中，名为 hostname-slow.log。如果希望使用一个不同的名字或路径，可以在 my.cnf 中使用 log-slow-queries = /new/path/to/file 实现此目的。
　　阅读慢速查询日志好是通过 mysqldumpslow 命令进行。指定日志文件的路径，可以看到一个慢速查询的排序后的列表，并且还显示了它们在日志文件中出现的次数。一个非常有用的特性是 mysqldumpslow 在比较结果之前，会删除任何用户指定的数据，因此对同一个查询的不同调用被计为一次;这可以帮助找出需要工作量多的查询。
　　对查询进行缓存
　　很多 LAMP 应用程序都严重依赖于数据库，但却会反复执行相同的查询。每次执行查询时，数据库都必须要执行相同的工作 —— 对查询进行分析，确定如何执行查询，从磁盘中加载信息，然后将结果返回给客户机。MySQL 有一个特性称为查询缓存，它将(后面会用到的)查询结果保存在内存中。在很多情况下，这会极大地提高性能。不过，问题是查询缓存在默认情况下是禁用的。
　　将 query_cache_size = 32M 添加到 /etc/my.conf 中可以启用 32MB 的查询缓存。
　　监视查询缓存
　　在启用查询缓存之后，重要的是要理解它是否得到了有效的使用。MySQL 有几个可以查看的变量，可以用来了解缓存中的情况。清单 2 给出了缓存的状态。
　　清单 2. 显示查询缓存的统计信息
　　mysql> SHOW STATUS LIKE 'qcache%';
　　+-------------------------+------------+
　　| Variable_name | Value |
　　+-------------------------+------------+
　　| Qcache_free_blocks | 5216 |
　　| Qcache_free_memory | 14640664 |
　　| Qcache_hits | 2581646882 |
　　| Qcache_inserts | 360210964 |
　　| Qcache_lowmem_prunes | 281680433 |
　　| Qcache_not_cached | 79740667 |
　　| Qcache_queries_in_cache | 16927 |
　　| Qcache_total_blocks | 47042 |
　　+-------------------------+------------+
　　8 rows in set (0.00 sec)
　　这些项的解释如表 1 所示。
　　表 1. MySQL 查询缓存变量
　　变量名 说明
　　Qcache_free_blocks 缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE 会对缓存中的碎片进行整理，从而得到一个空闲块。
　　Qcache_free_memory 缓存中的空闲内存。
　　Qcache_hits 每次查询在缓存中命中时增大。
　　Qcache_inserts 每次插入一个查询时增大。命中次数除以插入次数是不中比率;用 1 减去这个值是命中率。在上面这个例子中，大约有 87% 的查询都在缓存中命中。
　　Qcache_lowmem_prunes 缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字好长时间来看;如果这个数字在不断增长，表示可能碎片非常严重，或者内存很少。(上面的 free_blocks 和 free_memory 可以告诉您属于哪种情况)。
　　Qcache_not_cached 不适合进行缓存的查询的数量，通常是由于这些查询不是 SELECT 语句。
　　Qcache_queries_in_cache 当前缓存的查询(和响应)的数量。
　　Qcache_total_blocks 缓存中块的数量。
　　通常，间隔几秒显示这些变量可以看出区别，这可以帮助确定缓存是否正在有效地使用。运行 FLUSH STATUS 可以重置一些计数器，如果服务器已经运行了一段时间，这会非常有帮助。
　　使用非常大的查询缓存，期望可以缓存所有东西，这种想法非常诱人。由于 mysqld 必须要对缓存进行维护，例如当内存变得很低时执行剪除，因此服务器可能会在试图管理缓存时而陷入困境。作为一条规则，如果 FLUSH QUERY CACHE 占用了很长时间，那说明缓存太大了。
　　强制限制
　　您可以在 mysqld 中强制一些限制来确保系统负载不会导致资源耗尽的情况出现。清单 3 给出了 my.cnf 中与资源有关的一些重要设置。
　　清单 3. MySQL 资源设置
　　set-variable=max_connections=500set-variable=wait_timeout=10max_connect_errors = 100
　　连接大个数是在第一行中进行管理的。与 Apache 中的 MaxClients 类似，其想法是确保只建立服务允许数目的连接。要确定服务器上目前建立过的大连接数，请执行 SHOW STATUS LIKE 'max_used_connections'。
　　第 2 行告诉 mysqld 终止所有空闲时间超过 10 秒的连接。在 LAMP 应用程序中，连接数据库的时间通常是 Web 服务器处理请求所花费的时间。有时候，如果负载过重，连接会挂起，并且会占用连接表空间。如果有多个交互用户或使用了到数据库的持久连接，那么将这个值设低一点并不可取!
　　后一行是一个安全的方法。如果一个主机在连接到服务器时有问题，并重试很多次后放弃，那么这个主机会被锁定，直到 FLUSH HOSTS 之后才能运行。默认情况下，10 次失败足以导致锁定了。将这个值修改为 100 会给服务器足够的时间来从问题中恢复。如果重试 100 次都无法建立连接，那么使用再高的值也不会有太多帮助，可能它根本无法连接。
　　缓冲区和缓存
　　MySQL 支持超过 100 个的可调节设置;但是幸运的是，掌握少数几个可以满足大部分需要。查找这些设置的正确值可以通过 SHOW STATUS 命令查看状态变量，从中可以确定 mysqld 的运作情况是否符合我们的预期。给缓冲区和缓存分配的内存不能超过系统中的现有内存，因此调优通常都需要进行一些妥协。
　　MySQL 可调节设置可以应用于整个 mysqld 进程，也可以应用于单个客户机会话。
　　服务器端的设置
　　每个表都可以表示为磁盘上的一个文件，必须先打开，后读取。为了加快从文件中读取数据的过程，mysqld 对这些打开文件进行了缓存，其大数目由 /etc/mysqld.conf 中的 table_cache 指定。清单 4 给出了显示与打开表有关的活动的方式。
　　清单 4. 显示打开表的活动
　　mysql> SHOW STATUS LIKE 'open%tables';
　　+---------------+-------+
　　| Variable_name | Value |
　　+---------------+-------+
　　| Open_tables | 5000 |
　　| Opened_tables | 195 |
　　+---------------+-------+
　　2 rows in set (0.00 sec)
　　清单 4 说明目前有 5，000 个表是打开的，有 195 个表需要打开，因为现在缓存中已经没有可用文件描述符了(由于统计信息在前面已经清除了，因此可能会存在 5，000 个打开表中只有 195 个打开记录的情况)。如果 Opened_tables 随着重新运行 SHOW STATUS 命令快速增加，说明缓存命中率不够。如果 Open_tables 比 table_cache 设置小很多，说明该值太大了(不过有空间可以增长总不是什么坏事)。例如，使用 table_cache = 5000 可以调整表的缓存。
　　与表的缓存类似，对于线程来说也有一个缓存。 mysqld 在接收连接时会根据需要生成线程。在一个连接变化很快的繁忙服务器上，对线程进行缓存便于以后使用可以加快初的连接。
　　清单 5. 显示线程使用统计信息
　　mysql> SHOW STATUS LIKE 'threads%';
　　+-------------------+--------+
　　| Variable_name | Value |
　　+-------------------+--------+
　　| Threads_cached | 27 |
　　| Threads_connected | 15 |
　　| Threads_created | 838610 |
　　| Threads_running | 3 |
　　+-------------------+--------+
　　4 rows in set (0.00 sec)
　　此处重要的值是 Threads_created，每次 mysqld 需要创建一个新线程时，这个值都会增加。如果这个数字在连续执行 SHOW STATUS 命令时快速增加，应该尝试增大线程缓存。例如，可以在 my.cnf 中使用 thread_cache = 40 来实现此目的。
　　关键字缓冲区保存了 MyISAM 表的索引块。理想情况下，对于这些块的请求应该来自于内存，而不是来自于磁盘。清单 6 显示了如何确定有多少块是从磁盘中读取的，以及有多少块是从内存中读取的。
　　清单 6. 确定关键字效率
　　mysql> show status like '%key_read%';
　　+-------------------+-----------+
　　| Variable_name | Value |
　　+-------------------+-----------+
　　| Key_read_requests | 163554268 |
　　| Key_reads | 98247 |
　　+-------------------+-----------+
　　2 rows in set (0.00 sec)
　　Key_reads 代表命中磁盘的请求个数， Key_read_requests 是总数。命中磁盘的读请求数除以读请求总数是不中比率 —— 在本例中每 1，000 个请求，大约有 0.6 个没有命中内存。如果每 1，000 个请求中命中磁盘的数目超过 1 个，应该考虑增大关键字缓冲区了。例如，key_buffer = 384M 会将缓冲区设置为 384MB。
　　临时表可以在更高级的查询中使用，其中数据在进一步进行处理(例如 GROUP BY 字句)之前，都必须先保存到临时表中;理想情况下，在内存中创建临时表。但是如果临时表变得太大，需要写入磁盘中。清单 7 给出了与临时表创建有关的统计信息。