INSERT LOW_PRIORITY INTO mytable(id, username, city, age) VALUES(7, 'name7', 'city7', 70);
2、优化数据表
(1)优化表的数据类型
函数PROCEDURE ANALYSE()可以对数据表中的列的数据类型提出优化建议，根据实际情况考虑是否实施优化。(虽然应用设计的时候需要考虑字段的长度留有一定的冗余，但是不推荐让很多字段都留有大量的冗余，这样即浪费存储也浪费内存)
语法：
SELECT * FROM tbl_name PROCEDURE ANALYSE(); --输出的对数据表中的每一列的数据类型提出优化建议
SELECT * FROM tbl_name PROCEDURE ANALYSE(16,256);--不要为那些包含的值多于16个或者256字节的ENUM类型提出建议。(如果没有这样的限制，输出信息可能很长；ENUM定义通常很难阅读)
(2)拆分表提高访问效率
这里我们所说的拆分，主要是针对Myisam类型的表，拆分的方法可以分成两种情况：
纵向拆分：
纵向拆分是只按照应用访问的频度，将表中经常访问的字段和不经常访问的字段拆分成两个表，经常访问的字段尽量是定长的，这样可以有效的提高表的查询和更新的效率。
横向拆分：
横向拆分是指按照应用的情况，有目的的将数据横向拆分成几个表或者通过分区分到多个分区中，这样可以有效的避免Myisam表的读取和更新导致的锁问题。
(3)规范化和逆规范化
根据实际情况考虑以下两个需求：
规范化的需求：
规范化设计强调数据的独立性，数据应该尽可能少地冗余，因为存在过多的冗余数据，意味着要占用了更多的物理空间，同时也对数据的维护和一致性检查带来了麻烦。
逆规范化的需求：
对于查询操作很多的应用，一次查询可能需要访问多表进行，如果通过冗余相同数据纪录在一个表中，更新的代价增加不多，但是查询操作效率可以有明显提高。
(4)内存临时表
使用create temporary table语法创建临时表，它是基于session的表，数据保存在内存里面，当session断掉后，表自然消除。
比如，对于统计分析的表，如果统计的数据量不大，利用insert和select将数据移到临时表中比直接在表上做统计要效率更高。
(5)选择更合适的表类型
1）如果应用出现比较严重的锁冲突，请考虑是否更改存储引擎到innodb，行锁机制可以有效的减少锁冲突的出现。
2）如果应用查询操作很多，且对事务完整性要求不严格，则可以考虑使用Myisam存储引擎。
3、优化客户端应用
(1)使用连接池
对于访问数据库来说，建立连接的代价比较昂贵，因此，我们有必要建立"连接池"以提高访问的性能。
我们可以把连接当作对象或者设备，池中又有许多已经建立的连接，访问本来需要与数据库的连接的地方，都改为和池相连，池临时分配连接供访问使用，结果返回后，访问将连接交还。
(2)避免重复检索
理清访问逻辑，需要对相同表的访问，尽量集中在相同sql访问，一次提取结果，减少对数据库的重复访问。
4、优化数据库服务器
(1)使用mysql查询缓存
作用：
查询缓存存储SELECT查询的文本以及发送给客户端的相应结果。如果随后收到一个相同的查询，服务器从查询缓存中重新得到查询结果，而不再需要解析和执行查询。
适用范围：
不发生数据更新的表。当表更改（包括表结构和表数据）后，查询缓存值的相关条目会被清空。
查询缓存的主要参数：
SHOW VARIABLES LIKE '%query_cache%'; （或者 SHOW VARIABLES WHERE Variable_name LIKE '%query_cache%';) ：
have_query_cache 表示服务器在安装时已经配置了高速缓存
query_cache_size 表示缓存区大小，单位为字节(1024字节为1KB)
query_cache_type 值从0到2，含义分别为
0或者off（缓存关闭）
1或者on（缓存打开，使用sql_no_cache的select除外）
2或者demand（只有带sql_cache的select语句提供高速缓存）
SET GLOBAL query_cache_size=1024*50;
设置查询缓存大小，单位字节，1024字节为 1KB，query_cache_size大小的设置必须大于40KB
SHOW STATUS命令实时监视查询缓存:
SHOW STATUS LIKE '%Qcache%';
Qcache_queries_in_cache 在缓存中已注册的查询数目
Qcache_inserts 被加入到缓存中的查询数目
Qcache_hits 缓存采样数数目
Qcache_lowmem_prunes 因为缺少内存而被从缓存中删除的查询数目
Qcache_not_cached 没有被缓存的查询数目 (不能被缓存的，或由于 QUERY_CACHE_TYPE)
Qcache_free_memory 查询缓存的空闲内存总数
Qcache_free_blocks 查询缓存中的空闲内存块的数目
Qcache_total_blocks 查询缓存中的块的总数目
(2)使用机器高速缓存
Cache（高速缓存）、Memory（内存）、Hard disk（硬盘）都是数据存取单元，但存取速度却有很大差异，呈依次递减的顺序。
对于CPU来说，它可以从距离自己最近的Cache高速地存取数据，而不是从内存和硬盘以低几个数量级的速度来存取数据。
而Cache中所存储的数据，往往是CPU要反复存取的数据，有特定的机制（或程序）来保证Cache内数据的命中率（Hit Rate）。
因此，CPU存取数据的速度在应用高速缓存后得到了巨大的提高。
因为将数据写入高速缓存的任务由Cache Manager负责，所以对用户来说高速缓存的内容肯定是只读的。
需要你做的工作很少，程序中的SQL语句和直接访问DBMS时没有分别，返回的结果也看不出有什么差别。而数据库厂商往往会在DB Server的配置文件中提供与Cache相关的参数，通过修改它们，可针对我们的应用优化Cache的管理。
(3)均衡负载
1)读写分流（主从复制）
利用mysql的主从复制可以有效的分流更新操作和查询操作。
具体的实现是一个主服务器，承担更新操作（为了数据的一致性），多台从服务器，承担查询操作（多台从服务器一方面用来确保可用性，一方面可以创建不同的索引满足不同查询的需要），主从之间通过复制实现数据的同步。
主从复制优化：
对于主从之间不需要复制全部表的情况，可以通过在主的服务器上搭建一个虚拟的从服务器，将需要复制到从服务器的表设置成blackhole引擎，然后定义replicate-do-table参数只复制这些表，这样就过滤出需要复制的binlog，减少了传输binlog的带宽。因为搭建的虚拟的从服务器只起到过滤binlog的作用，并没有实际纪录任何数据，所以对主数据库服务器的性能影响也非常的有限。
注意：
通过复制分流查询的存在的问题是主数据库上更新频繁或者网络出现问题的时候，主从之间的数据可能存在差异，造成查询结果的异议，应用在设计的时候需要有所考虑。
2)分布式的数据库
分布式的数据库设计适合大数据量，负载高