有一个特别大的访问量到数据库上，如何优化？
1.使用索引：应尽量避免全表扫描， 首先应考虑在 where 及 order by ,group by 涉及的列上建立索引 。
2.优化sql语句：
a.使用explain查看sql语句的执行效果，以选择更好的索引和查询语句。e.g. explain select S_id from S;
b.不使用*，用具体的字段代替*；
c.不在索引列做运算或使用函数；
d.尽可能使用limit减少返回的行数，减少数据的传输时间和带宽的浪费。
3.优化数据库对象
a.优化表的数据类型：使用procedure analyse()函数对表进行分析，数据类型能用小就用小。e.g. select * from S precedure analyse();
b.对表进行拆分，包括垂直拆分（常用属性一个表、不常用属性一个表）、水平拆分；
c.使用中间表提高查询速度：比如说数据库中有近两年的业务数据，领导让你统计一下本周的业务情况，就可以创建一个中间表，该表结构个原表结构完全相同，把本周的数据转移到中间表中，然后在中间表中进行统计。
4.优化硬件
CPU：多核、主频高
内存：更大的内存，将尽可能多的内存分配给数据库做缓存。
磁盘：使用磁盘阵列、调整磁盘调度算法以减少磁盘寻道时间。
5.数据库自身的优化：e.g.指定查询缓冲区的大小、指定数据库允许的最大连接进程数。。。
6.优化应用
a.使用数据库连接池
b.使用查询缓存：查询缓存可以存储select语句和相应结果。当表中数据更改后，查询缓存中的相关条目就会被清空，适合更新不频繁的表。
前面6个是从查询的角度优化，还可以进行：主从复制、读写分离、负载均衡
目前，大部分的主流关系型数据库都提供了主从复制的功能，通过配置两台（或多台） 数据库的主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。网站可 以利用数据库的这一功能，实现数据库的读写分离，从而改善数据库的负载压力。因为一个系统的读操作远远多于写操作，所以写操作发向 master，读操作发向 slaves 进行操作（简 单的轮循算法来决定使用哪个 slave）。 利用数据库的读写分离，Web 服务器在写数据的时候，访问主数据库（Master），主数据库通过主从复制机制将数据更新同步到从数据库（Slave），这样当 Web 服务器读数 据的时候，就可以通过从数据库获得数据。这一方案使得在大量读操作的 Web 应用可以轻松地读取数据，而主数据库也只会承受少量的写入操作，还可以实现数据热备份，可谓是 一举两得的方案。
sql语句的安全性
1）防止sql注入
2）当 sql 语句运行出错时， 不要把数据库返回的错误信息全部显示给用户， 以防止 泄漏服务器和数据库相关信息。
sql注入和防止？
在sql语句拼接的情况下非常容易发生sql注入，比如我们只允许用户查询一年级学生的成绩，select score from S where grade='一年级' 但是用户可通过给该语句拼接‘and 1=1’查看全部学生的成绩。
1）参数绑定：填充的方法。只允许用户使用设置grade的值
2）检查变量的数据类型和格式
3）将所有的sql语句封装在存储过程中
存储过程：
就是一些编译好了的 sql 语句， 这些 SQL 语句代码 像一个方法一样实现一些功能（对单表或多表的增删改查） ， 然后 再给这个代码块取一个名字， 在用到这个功能的时候调用他就行了。
优点：
1.存储过程因为 SQL 语句已经预编译过了， 因此运行的速度比 较快。
2.存储过程在服务器端运行， 减少客户端的压力。
3.允许模块化程序设计， 一次创建、多次使用。
4.减少网络流量， 客户端调用存储过程只需要传存储过程名和相 关参数即可， 与传输 SQL 语句相比自然数据量少了很多。
5. 增强了使用的安全性， 充分利用系统管理员可以对执行的某 一个存储过程进行权限限制， 从而能够实现对某些数据访问的限制， 避免非授权用户对数据的访问， 保证数据的安全。 程序员直接调用 存储过程， 根本不知道表结构是什么， 有什么字段， 没有直接暴露 表名以及字段名给程序员。
缺点： 调试麻烦（至少没有像开发程序那样容易），可移植性不灵活（因 为存储过程是依赖于具体的数据库）
P.S.
磁盘阵列：RAID 0 没有数据冗余， 没有数据校验的磁盘阵列。 实现 RAID 0 至少需要两块以上的硬盘， 它将两块以上的硬盘合并成一块， 数据 连续地分割在每块盘上。 RAID1 是将一个两块硬盘所构成 RAID 磁盘阵列， 其容量仅等于 一块硬盘的容量， 因为另一块只是当作数据“镜像”。 使用 RAID-0+1 磁盘阵列。 RAID 0+1 是 RAID 0 和 RAID 1 的组 合形式。 它在提供与 RAID 1 一样的数据安全保障的同时， 也提供了 与 RAID 0 近似的存储性能。
mysql 主(称 master)从(称 slave)复制的原理：
(1)master 将数据改变记录到二进制日志(binary log)中,也即是配置文件 log-bin 指定 的文件(这些记录叫做二进制日志事件， binary log events)
Slave 服务器中有一个I/O线程(I/O Thread)在不停地监听 Master 的二进制日志(Binary Log)是否有更新： 如果没有它会睡眠等待 Master 产生新的日志事件； 如果有新的日志事件(Log Events)， 则会将其拷贝至 Slave 服务器中的中继日志(Relay Log)。
(2).slave 将 master 的二进制日志事件（binary log events）拷贝到它的中继日志(relay log)
(3).slave 重做中继日志中的事件,将 Master 上的改变反映到它自己的数据库中。 所 以两端的数据是完全一样的。
主从复制的几种方式：
1.同步复制：主服务器在将更新的数据写入它的二进制日志（Binlog）文件中后，必须等待验证所有的从服务器的更新数据是否已经复制到其中，之后才可以自由处理其它进入的事务处理请求。
2.异步复制：主服务器在将更新的数据写入它的二进制日志（Binlog）文件中后，无需等待验证更新数据是否已经复制到从服务器中，就可以自由处理其它进入的事务处理请求。
3.半同步复制：主服务器在将更新的数据写入它的二进制日志（Binlog）文件中后，只需等待验证其中一台从服务器的更新数据是否已经复制到其中，就可以自由处理其它进入的事务处理请求，其他的从服务器不用管。