数据库慢同步

Ⅰ 连接服务器数据库超慢怎么解决

首先检查网络是否有问题。然后查看数据库服务器性能。cpu，内存，硬盘的读写。这些都会有影响。然后打开mysql慢查询日志。
如果可以的话你把你两台服务器的环境说一下。

Ⅱ 如何解决主从数据库同步延迟问题

最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行。还有就是主库是写，对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不需要这么高的数据安全，完全可以讲sync_binlog设置为0或者关闭binlog，innodb_flushlog也可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave。
mysql-5.6.3已经支持了多线程的主从复制。原理和丁奇的类似，丁奇的是以表做多线程，Oracle使用的是以数据库(schema)为单位做多线程，不同的库可以使用不同的复制线程。
sync_binlog=1
This makes MySQL synchronize the binary log’s contents to disk each time it commits a transaction
默认情况下，并不是每次写入时都将binlog与硬盘同步。因此如果操作系统或机器(不仅仅是MySQL服务器)崩溃，有可能binlog中最后的语句丢 失了。要想防止这种情况，你可以使用sync_binlog全局变量(1是最安全的值，但也是最慢的)，使binlog在每N次binlog写入后与硬盘 同步。即使sync_binlog设置为1,出现崩溃时，也有可能表内容和binlog内容之间存在不一致性。如果使用InnoDB表，MySQL服务器 处理COMMIT语句，它将整个事务写入binlog并将事务提交到InnoDB中。如果在两次操作之间出现崩溃，重启时，事务被InnoDB回滚，但仍 然存在binlog中。可以用--innodb-safe-binlog选项来增加InnoDB表内容和binlog之间的一致性。(注释：在MySQL 5.1中不需要--innodb-safe-binlog；由于引入了XA事务支持，该选项作废了），该选项可以提供更大程度的安全，使每个事务的 binlog(sync_binlog =1)和(默认情况为真)InnoDB日志与硬盘同步，该选项的效果是崩溃后重启时，在滚回事务后，MySQL服务器从binlog剪切回滚的 InnoDB事务。这样可以确保binlog反馈InnoDB表的确切数据等，并使从服务器保持与主服务器保持同步(不接收 回滚的语句)。
innodb_flush_log_at_trx_commit （这个很管用）
抱怨Innodb比MyISAM慢 100倍？那么你大概是忘了调整这个值。默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电 池供电缓存（Battery backed up cache）时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统 挂了时才可能丢数据。

Ⅲ oracle 数据库很慢，应该如何优化

1、是这样的。
2、这个说不好，我没这么做过。你手边应该有oralce的全套电子文档吧。关键是你要找对系统表或者视图。我记得索引的系统视图不是这个。
3、这些与你要做的有关系吗？别像没头苍蝇一样瞎撞了。
4、不用删表，如果你连基本的语句命令都不懂，那只能看书了。
5、慢的原因有好多，逐步排除吧，等找到真正原因再说。急没用的。
6、默认情况下，是会建到用户的默认表空间的。
7、这个看你的维护需要。最起码先弄明白你的库是怎么回事再说吧。就从这些问题看，你根本就是门外汉，连库是怎么回事都没弄明白。

Ⅳ 当数据库变慢时的解决方法有哪些

我们使用电脑和手机时候最不能忍受就是设备又卡又慢了,严重影响我们工作或者游戏体验。当数据库变慢时，我们应如何入手，下面的解决方法。

方法步骤

第一章 检查系统的状态

1.1 使用sar来检查操作系统是否存在IO问题

1.2 关注内存vmstat

1.3 找到使用资源特别大的Oracle的session及其执行的语句

1.4 查找前十条性能差的sql语句

当数据库变慢时，我们应如何入手

当应用管理员通告现在应用很慢、数据库很慢时，当Oracle DBA在数据库上做几个示例的Select也发现同样的问题时，有些时侯就会无从下手，因为DBA认为数据库的各种命种率都是满足Oracle文档的建议。实际上如今的优化己经向优化等待(waits)转型了，实际中性能优化最根本的出现点也都集中在I/O，这是影响性能最主要的方面，由系统中的等待去发现Oracle库中的不足、操作系统某些资源利用的不合理是一个比较好的办法。下面把一些实践经验与大家分享，本文测重于Unix环境。

第一章 检查系统的状态

通过操作系统的一些工具检查系统的状态，比如CPU、内存、交换、磁盘的利用率，根据经验或与系统正常时的状态相比对，有时系统表面上看起来看空闲，这也可能不是一个正常的状态，因为cpu可能正等待IO的完成。除此之外，还应观注那些占用系统资源(cpu、内存)的进程。

1.1 使用sar来检查操作系统是否存在IO问题

#sar -u 2 10 -- 即每隔2秒检察一次，共执行20次。

结果示例：

注：在redhat下，%system就是所谓的%wio。

Linux 2.4.21-20.ELsmp (YY075) 05/19/2005

10:36:07 AM CPU %user %nice %system %idle

10:36:09 AM all 0.00 0.00 0.13 99.87

10:36:11 AM all 0.00 0.00 0.00 100.00

10:36:13 AM all 0.25 0.00 0.25 99.49

10:36:15 AM all 0.13 0.00 0.13 99.75

10:36:17 AM all 0.00 0.00 0.00 100.00

其中：

Ø %usr指的是用户进程使用的cpu资源的百分比;

Ø %sys指的是系统资源使用cpu资源的百分比;

Ø %wio指的是等待io完成的百分比，这是值得观注的一项;

Ø %idle即空闲的百分比。

如果wio列的值很大，如在35%以上，说明系统的IO存在瓶颈，CPU花费了很大的时间去等待I/O的完成。Idle很小说明系统CPU很忙。像以上的示例，可以看到wio平均值为11，说明I/O没什么特别的问题，而idle值为零，说明cpu已经满负荷运行了。

当系统存在IO问题时，可以从以下几个方面解决：

Ø 联系相应的操作系统的技术支持对这方面进行优化，比如hp-ux在划定卷组时的条带化等方面。

Ø 查找Oracle中不合理的sql语句，对其进行优化;

Ø 对Oracle中访问量频繁的表除合理建索引外，再就是把这些表分表空间存放以免访问上产生热点，再有就是对表合理分区。

1.2 关注内存

常用的工具便是vmstat，对于hp-unix来说，可以用glance。Aix来说可以用topas。当发现vmstat中pi列非零，memory中的free列的值很小，glance、topas中内存的利用率多于80%时，这时说明内存方面应该调节一下。方法大体有以下几项：

Ø 划给Oracle使用的内存不要超过系统内存的1/2，一般保在系统内存的40%为益。

Ø 为系统增加内存;

Ø 如果你的连接特别多，可以使用MTS的方式;

Ø 打全补丁，防止内存漏洞。

1.3 找到使用资源特别大的Oracle的session及其执行的语句

Hp-unix可以用glance或top。IBM AIX可以用topas。此外可以使用ps的命令。

通过这些程序可以找到点用系统资源特别大的这些进程的进程号，就可以通过以下的sql语句发现这个pid正在执行哪个sql，这个sql最好在pl/sql developer、toad等软件中执行：

SELECT a.username, a.machine, a.program, a.sid, a.serial#, a.status,

c.piece, c.sql_text

FROM v$session a, v$process b, v$sqltext c

WHERE b.spid = 'ORCL'

AND b.addr = a.paddr

AND a.sql_address = c.address(+)

ORDER BY c.piece;

可以把得到的这个sql分析一下，看一下它的执行计划是否走索引。对其优化避免全表扫描，以减少IO等待，从而加快语句的执行速度。

提示：在做优化sql时，经常碰到使用in的语句，这时一定要用exists把它给换掉，因为Oracle在处理In时是按Or的方式做的，即使使用了索引也会很慢。比如：

SELECT col1, col2, col3 FROM table1 a

WHERE a.col1 NOT IN (SELECT col1 FROM table2)

可以换成：

SELECT col1, col2, col3 FROM table1 a

WHERE NOT EXISTS

(SELECT 'x' FROM table2 b WHERE a.col1=b.col1)

1.4 查找前十条性能差的sql语句

SELECT * FROM (SELECT parsing_user_id, executions, sorts, command_type,

disk_reads, sql_text FROM v$sqlarea

ORDER BY disk_reads DESC)

WHERE ROWNUM<10;

第二章 检查会话状态

要快速发现Oracle Server的性能问题的原因，可以求助于v$session_wait视图，看系统的这些session在等什么，使用了多少的IO。以下是参考脚本：

-- 脚本说明：查看占I/O较大的正在运行的session：

SELECT se.sid, se.serial#, pr.spid, se.username, se.status, se.terminal,

se.program, se.mole, se.sql_address, st.event, st.p1text,

si.physical_reads, si.block_changes

FROM v$session se, v$session_wait st, v$sess_io si, v$process pr

WHERE st.sid=se.sid AND st.sid=si.sid

AND se.PADDR=pr.ADDR

AND se.sid>6

AND st.wait_time=0

AND st.event NOT LIKE '%SQL%'

ORDER BY physical_reads DESC;

对检索出的结果的几点说明：

1. 以上是按每个正在等待的session已经发生的物理读排的序，因为它与实际的I/O相关。

2. 可以看一下这些等待的进程都在忙什么，语句是否合理?

SELECT sql_address FROM v$session WHERE sid=;

SELECT * FROM v$sqltext WHERE address=;

执行以上两个语句便可以得到这个session的语句。

也以用alter system kill session 'sid, serial#';把这个session杀掉。

3. 应观注一下event列，这是调优的关键一列，下面对常出现的event做以简要的说明：

1) buffer busy waits，free buffer waits这两个参数所标识是dbwr是否够用的问题，与IO很大相关的，当v$session_wait中的free buffer wait的条目很小或没有时，说明系统的dbwr进程决对够用，不用调整;free buffer wait的条目很多，系统感觉起来一定很慢，这时说明dbwr已经不够用了，它产生的wio已经成为数据库性能的瓶颈，这时的解决办法如下：

Ø 增加写进程，同时要调整db_block_lru_latches参数：

示例：修改或添加如下两个参数

db_writer_processes=4

db_block_lru_latches=8

Ø 开异步IO。IBM这方面简单得多，hp则麻烦一些，可以与Hp工程师联系。

2) db file sequential read，指的是顺序读，即全表扫描，这也是应尽量减少的部分，解决方法就是使用索引、sql调优，同时可以增大db_file_multiblock_read_count这个参数。

3) db file scattered read参数指的是通过索引来读取，同样可以通过增加db_file_multiblock_read_count这个参数来提高性能。

4) latch free与栓相关，需要专门调节。

5) 其他参数可以不特别观注

补充：解决系统变慢的常用技巧方法

1、在我的电脑窗口，右击要清理的盘符―“属性”―“清理磁盘”--勾选要删除的文件--确定--是。

2、右键浏览器e――属性――点2个删除1个清除(都要逐一确定)――确定 。

3、把C:WINDOWSPrefetch(预读文件)把里面的文件全部删除

4、用优化大师或超级兔子清理注册表和垃圾文件。

5、“开始”――运行中输入msconfig――确定――启动――除了输入法ctfmon以外的勾全去掉。

6、右键我的电脑”――属性――点高级――点启动和故障恢复中的设置――去掉所有的勾――写入调试信息选择“无”――确定――点高级下面错误报告――点禁用――2次确定。

7、“开始”..打开控制面板中的文件夹选项..点查看..点去末项自动搜索文件夹前面的勾..确定。

8、右键我的电脑――属性――硬件――设备管理器――双击IDE控制器――次要通道――高级设置――传送模式都选DMA――设备类型选无――确定――主要通道也同样设置――确定。

9、右键C盘进行磁盘清理和其它选项中的系统还原清理。

Ⅳ 我的程序，查询数据库很慢。请问怎么提高查询速度

SQL提高查询效率

1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。

2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0

3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。

4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20

5.in 和 not in 也要慎用，否则会导致全表扫描，如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3

6.下面的查询也将导致全表扫描：
select id from t where name like '%abc%'
若要提高效率，可以考虑全文检索。

7.如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num

8.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100
应改为:
select id from t where num=100*2

9.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)='abc'--name以abc开头的id
select id from t where datediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id
应改为:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'

10.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

11.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。

12.不要写一些没有意义的查询，如需要生成一个空表结构：
select col1,col2 into #t from t where 1=0
这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：
create table #t(...)

13.很多时候用 exists 代替 in 是一个好的选择：
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)

14.并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。

15.索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。

16.应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。

17.尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。

18.尽可能的使用 varchar/nvarchar 代替 char/nchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。

19.任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。

20.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。

21.避免频繁创建和删除临时表，以减少系统表资源的消耗。

22.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。

23.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。

24.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。

25.尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。

26.使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。

27.与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。

28.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。

29.尽量避免大事务操作，提高系统并发能力。

30.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理

1、避免将字段设为“允许为空”
2、数据表设计要规范
3、深入分析数据操作所要对数据库进行的操作
4、尽量不要使用临时表
5、多多使用事务
6、尽量不要使用游标
7、避免死锁
8、要注意读写锁的使用
9、不要打开大的数据集
10、不要使用服务器端游标
11、在程序编码时使用大数据量的数据库
12、不要给“性别”列创建索引
13、注意超时问题
14、不要使用Select *
15、在细节表中插入纪录时，不要在主表执行Select MAX(ID)
16、尽量不要使用TEXT数据类型
17、使用参数查询
18、不要使用Insert导入大批的数据
19、学会分析查询
20、使用参照完整性
21、用INNER JOIN 和LEFT JOIN代替Where

提高SQL查询效率（要点与技巧）：
· 技巧一：
问题类型：ACCESS数据库字段中含有日文片假名或其它不明字符时查询会提示内存溢出。
解决方法：修改查询语句
sql="select * from tablename where column like '%"&word&"%'"
改为
sql="select * from tablename"
rs.filter = " column like '%"&word&"%'"
===========================================================
技巧二：
问题类型：如何用简易的办法实现类似网络的多关键词查询（多关键词用空格或其它符号间隔）。
解决方法：
'//用空格分割查询字符串
ck=split(word," ")
'//得到分割后的数量
sck=UBound(ck)
sql="select * tablename where"
在一个字段中查询
For i = 0 To sck
SQL = SQL & tempJoinWord & "(" & _
"column like '"&ck(i)&"%')"
tempJoinWord = " and "
Next
在二个字段中同时查询
For i = 0 To sck
SQL = SQL & tempJoinWord & "(" & _
"column like '"&ck(i)&"%' or " & _
"column1 like '"&ck(i)&"%')"
tempJoinWord = " and "
Next
===========================================================
技巧三：大大提高查询效率的几种技巧

1. 尽量不要使用 or，使用or会引起全表扫描，将大大降低查询效率。
2. 经过实践验证，charindex()并不比前面加%的like更能提高查询效率，并且charindex()会使索引失去作用（指sqlserver数据库）
3. column like '%"&word&"%' 会使索引不起作用
column like '"&word&"%' 会使索引起作用（去掉前面的%符号）
（指sqlserver数据库）
4. '%"&word&"%' 与'"&word&"%' 在查询时的区别：
比如你的字段内容为 一个容易受伤的女人
'%"&word&"%' ：会通配所有字符串，不论查“受伤”还是查“一个”，都会显示结果。
'"&word&"%' ：只通配前面的字符串，例如查“受伤”是没有结果的，只有查“一个”，才会显示结果。
5. 字段提取要按照“需多少、提多少”的原则，避免“select *”，尽量使用“select 字段1,字段2,字段3........”。实践证明：每少提取一个字段，数据的提取速度就会有相应的提升。提升的速度还要看您舍弃的字段的大小来判断。
6. order by按聚集索引列排序效率最高。一个sqlserver数据表只能建立一个聚集索引，一般默认为ID，也可以改为其它的字段。
7. 为你的表建立适当的索引，建立索引可以使你的查询速度提高几十几百倍。（指sqlserver数据库）
· 以下是建立索引与不建立索引的一个查询效率分析：
Sqlserver索引与查询效率分析。
表 News
字段
Id：自动编号
Title：文章标题
Author：作者
Content：内容
Star：优先级
Addtime：时间
记录：100万条
测试机器：P4 2.8/1G内存/IDE硬盘
=======================================================
方案1：
主键Id，默认为聚集索引，不建立其它非聚集索引
select * from News where Title like '%"&word&"%' or Author like '%"&word&"%' order by Id desc
从字段Title和Author中模糊检索，按Id排序
查询时间：50秒
=======================================================
方案2：
主键Id，默认为聚集索引
在Title、Author、Star上建立非聚集索引
select * from News where Title like '"&word&"%' or Author like '"&word&"%' order by Id desc
从字段Title和Author中模糊检索，按Id排序
查询时间：2 - 2.5秒
=======================================================
方案3：
主键Id，默认为聚集索引
在Title、Author、Star上建立非聚集索引
select * from News where Title like '"&word&"%' or Author like '"&word&"%' order by Star desc
从字段Title和Author中模糊检索，按Star排序
查询时间：2 秒
=======================================================
方案4：
主键Id，默认为聚集索引
在Title、Author、Star上建立非聚集索引
select * from News where Title like '"&word&"%' or Author like '"&word&"%'
从字段Title和Author中模糊检索，不排序
查询时间：1.8 - 2 秒
=======================================================
方案5：
主键Id，默认为聚集索引
在Title、Author、Star上建立非聚集索引
select * from News where Title like '"&word&"%'
或
select * from News where Author like '"&word&"%'
从字段Title 或 Author中检索，不排序
查询时间：1秒
· 如何提高SQL语言的查询效率?
问：请问我如何才能提高SQL语言的查询效率呢？
答：这得从头说起：
由于SQL是面向结果而不是面向过程的查询语言，所以一般支持SQL语言的大型关系型数据库都使用一个基于查询成本的优化器，为即时查询提供一个最佳的执行策略。对于优化器，输入是一条查询语句，输出是一个执行策略。
一条SQL查询语句可以有多种执行策略，优化器将估计出全部执行方法中所需时间最少的所谓成本最低的那一种方法。所有优化都是基于用记所使用的查询语句中的where子句，优化器对where子句中的优化主要用搜索参数(Serach Argument)。
搜索参数的核心思想就是数据库使用表中字段的索引来查询数据，而不必直接查询记录中的数据。
带有 =、<、<=、>、>= 等操作符的条件语句可以直接使用索引，如下列是搜索参数：
emp_id = "10001" 或 salary > 3000 或 a =1 and c = 7
而下列则不是搜索参数：
salary = emp_salary 或 dep_id != 10 或 salary * 12 >= 3000 或 a=1 or c=7
应当尽可能提供一些冗余的搜索参数，使优化器有更多的选择余地。请看以下3种方法：
第一种方法：
select employee.emp_name,department.dep_name from department,employee where (employee.dep_id = department.dep_id) and (department.dep_code="01") and (employee.dep_code="01");
它的搜索分析结果如下：
Estimate 2 I/O operations
Scan department using primary key
for rows where dep_code equals "01"
Estimate getting here 1 times
Scan employee sequentially
Estimate getting here 5 times
第二种方法：
select employee.emp_name,department.dep_name from department,employee where (employee.dep_id = department.dep_id) and (department.dep_code="01");
它的搜索分析结果如下：
Estimate 2 I/O operations
Scan department using primary key
for rows where dep_code equals "01"
Estimate getting here 1 times
Scan employee sequentially
Estimate getting here 5 times
第一种方法与第二种运行效率相同，但第一种方法最好，因为它为优化器提供了更多的选择机会。
第三种方法：
select employee.emp_name,department.dep_name from department,employee where (employee.dep_id = department.dep_id) and (employee.dep_code="01");
这种方法最不好，因为它无法使用索引，也就是无法优化……
使用SQL语句时应注意以下几点：
1、避免使用不兼容的数据类型。例如，Float和Integer，Char和Varchar，Binary和Long Binary不兼容的。数据类型的不兼容可能使优化器无法执行一些本可以进行的优化操作。例如：
select emp_name form employee where salary > 3000;
在此语句中若salary是Float类型的，则优化器很难对其进行优化，因为3000是个整数，我们应在编程时使用3000.0而不要等运行时让DBMS进行转化。
2、尽量不要使用表达式，因它在编绎时是无法得到的，所以SQL只能使用其平均密度来估计将要命中的记录数。
3、避免对搜索参数使用其他的数学操作符。如：
select emp_name from employee where salary * 12 > 3000;
应改为：
select emp_name from employee where salary > 250;
4、避免使用 != 或 <> 等这样的操作符，因为它会使系统无法使用索引，而只能直接搜索表中的数据。
· ORACAL中的应用
一个1600万数据表－－短信上行表TBL_SMS_MO
结构：
CREATE TABLE TBL_SMS_MO
(
SMS_ID NUMBER,
MO_ID VARCHAR2(50),
MOBILE VARCHAR2(11),
SPNUMBER VARCHAR2(20),
MESSAGE VARCHAR2(150),
TRADE_CODE VARCHAR2(20),
LINK_ID VARCHAR2(50),
GATEWAY_ID NUMBER,
GATEWAY_PORT NUMBER,
MO_TIME DATE DEFAULT SYSDATE
);
CREATE INDEX IDX_MO_DATE ON TBL_SMS_MO (MO_TIME)
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE
(
INITIAL 1M
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
);
CREATE INDEX IDX_MO_MOBILE ON TBL_SMS_MO (MOBILE)
PCTFREE 10
INITRANS 2
MAXTRANS 255
STORAGE
(
INITIAL 64K
NEXT 1M
MINEXTENTS 1
MAXEXTENTS UNLIMITED
PCTINCREASE 0
);
问题：从表中查询某时间段内某手机发送的短消息，如下SQL语句：
SELECT MOBILE,MESSAGE,TRADE_CODE,MO_TIME
FROM TBL_SMS_MO
WHERE MOBILE='130XXXXXXXX'
AND MO_TIME BETWEEN TO_DATE('2006-04-01','YYYY-MM-DD HH24:MI:SS') AND TO_DATE('2006-04-07','YYYY-MM-DD HH24:MI:SS')
ORDER BY MO_TIME DESC
返回结果大约需要10分钟，应用于网页查询，简直难以忍受。
分析：
在PL/SQL Developer，点击“Explain Plan”按钮（或F5键），对SQL进行分析，发现缺省使用的索引是IDX_MO_DATE。问题可能出在这里，因为相对于总数量1600万数据来说，都mobile的数据是很少的，如果使用IDX_MO_MOBILE比较容易锁定数据。
如下优化：
SELECT /*+ index(TBL_SMS_MO IDX_MO_MOBILE) */ MOBILE,MESSAGE,TRADE_CODE,MO_TIME
FROM TBL_SMS_MO
WHERE MOBILE='130XXXXXXXX'
AND MO_TIME BETWEEN TO_DATE('2006-04-01','YYYY-MM-DD HH24:MI:SS') AND TO_DATE('2006-04-07','YYYY-MM-DD HH24:MI:SS')
ORDER BY MO_TIME DESC
测试：
按F8运行这个SQL，哇～... ... 2.360s，这就是差别。
http://www.cnblogs.com/ShaYeBlog/archive/2013/07/31/3227244.html

Ⅵ mysql数据库表太大查询慢优化的几种方法

优化方案：
主从同步+读写分离：
这个表在有设备条件的情况下，读写分离，这样能减少很多压力，而且数据稳定性也能提高
纵向分表：
根据原则，每个表最多不要超过5个索引，纵向拆分字段，将部分字段拆到一个新表
通常我们按以下原则进行垂直拆分:（先区分这个表中的冷热数据字段）
把不常用的字段单独放在一张表;
把text，blob等大字段拆分出来放在附表中;
经常组合查询的列放在一张表中;
缺点是：很多逻辑需要重写，带来很大的工作量。
利用表分区：
这个是推荐的一个解决方案，不会带来重写逻辑等，可以根据时间来进行表分区，相当于在同一个磁盘上，表的数据存在不同的文件夹内，能够极大的提高查询速度。
横向分表：
1000W条数据不少的，会带来一些运维压力，备份的时候，单表备份所需时间会很长，所以可以根据服务器硬件条件进行水平分表，每个表有多少数据为准。

Ⅶ 如何提高速度让数据同步到数据库时间最优化

下面以关系数据库系统Informix为例，介绍改善用户查询计划的方法。

1．合理使用索引

索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处，其使用原则如下：

●在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。

●在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。

●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。

●如果待排序的列有多个，可以在这些列上建立复合索引（compound index）。

●使用系统工具。如Informix数据库有一个tbcheck工具，可以在可疑的索引上进行检查。在一些数据库服务器上，索引可能失效或者因为频繁操作而使得读取效率降低，如果一个使用索引的查询不明不白地慢下来，可以试着用tbcheck工具检查索引的完整性，必要时进行修复。另外，当数据库表更新大量数据后，删除并重建索引可以提高查询速度。

2．避免或简化排序

应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：

●索引中不包括一个或几个待排序的列；

●group by或order by子句中列的次序与索引的次序不一样；

●排序的列来自不同的表。

为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。

3．消除对大型表行数据的顺序存取

在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄……）和选课表（学号、课程号、成绩）。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。

还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作：

SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008

虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：

SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001

UNION

SELECT ＊ FROM orders WHERE order_num=1008

这样就能利用索引路径处理查询。

4．避免相关子查询

一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。

5．避免困难的正规表达式

MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _”

即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT ＊ FROM customer WHERE zipcode >“98000”，在执行查询时就会利用索引来查询，显然会大大提高速度。

另外，还要避免非开始的子串。例如语句：SELECT ＊ FROM customer WHERE zipcode[2，3]>“80”，在where子句中采用了非开始子串，因而这个语句也不会使用索引。

6．使用临时表加速查询

把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。例如：

SELECT cust.name，rcvbles.balance，……other columns

FROM cust，rcvbles

WHERE cust.customer_id = rcvlbes.customer_id

AND rcvblls.balance>0

AND cust.postcode>“98000”

ORDER BY cust.name

如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序：

SELECT cust.name，rcvbles.balance，……other columns

FROM cust，rcvbles

WHERE cust.customer_id = rcvlbes.customer_id

AND rcvblls.balance>0

ORDER BY cust.name

INTO TEMP cust_with_balance

然后以下面的方式在临时表中查询：

SELECT ＊ FROM cust_with_balance

WHERE postcode>“98000”

临时表中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。

注意：临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下，注意不要丢失数据。

7．用排序来取代非顺序存取

非顺序磁盘存取是最慢的操作，表现在磁盘存取臂的来回移动。SQL语句隐藏了这一情况，使得我们在写应用程序时很容易写出要求存取大量非顺序页的查询。

有些时候，用数据库的排序能力来替代非顺序的存取能改进查询。

Ⅷ 数据库和应用分开部署访问变慢

数据库慢一般有三种情况第一种情况 逐渐变慢 要建立一个长期的监控机制 比如 写个shell脚本每天的忙时(通常 ~ etc )定时收集os neork db的信息 每个星期出report对收集到的信息进行分析 这些数据的积累 可以决定后期的优化决策 并且可以是DBA说服manager采用自己决策的重要数据 DBA的价值 就在每个星期的report中体现
第二种情况 突然变慢 也是最容易解决的 先从业务的角度看是DB的使用跟以前有何不同 然后做进一步判断 硬件/网络故障通常也会引起DB性能的突然下降
第一步: 察看DB/OS/NEORK的系统log 排除硬件/网络问题
第二步 察看数据库的等待事件 根据等待事件来判断可能出问题的环节 如果 没有等待事件 可以排除数据库的问题 如果有等待时间 根据不同的等待事件 来找引起这些事件的根源
比如latch free等跟SQL parse有关系的等待事件 OS的表现是CPU 的占用率高
db file scattered read等跟SQL disk read有关系的等待时间 OS的表现是iostat可以看到磁盘读写量增加
第三步: 察看os的信息 CPU/IO/MEMORY等
a Cpu 的占用率
CPU占用率与数据库性能不成反比 CPU占用率高 不能说明数据库性能慢 通常情况 一个优化很好 而且业务量确实很大的数据库 CPU的占用率都会高 而且会平均分布在每个进程上 反过来 CPU的占用率都会高也不代表数据库性能就好 要结合数据库的等待事件来判断CPU占用率高是否合理
如果某个进程的cpu占用高 肯定是这个进程有问题 如果 不是oracle的进程 可以让application察看是否程序有死循环等漏洞 如果 是oracle的进程 可以根据pid查找oracle数据字典看看这个进程的发起程序 正在执行的sql语句 以及等待事件 然后 不同情况使用不同的方法来解决
b IO
排除硬件的IO问题 数据库突然变慢 一般来说 都是一个或几个SQL语句引起的
如果IO很频繁 可以通过优化disk reads高的TOP SQL来解决 当然这也是解决IO问题的最笨也是最有效的办法
OS以及存储的配置也是影响IO的一个重要的原因
比如 最常见的HP unix下异步IO的问题 如果DBA GROUP没有MLOCK的权限 ORACLE是不使用AIO的 偏偏OS与DB的两方的admin如果配合不够好地话 这个配置就很容易给漏掉了
c Memory
第二种情况与memory的关系比较小 只要SGA区配置合理没有变化 一般来说 只要不是Application Memory leak 不会引起突然变慢的现象
第三种情况 不定时变慢 是最难解决的 现场出现的问题原因也是五花八门千奇百怪 最重要的是 出现慢的现象时 以最快的速度抓取到最多的信息以供分析 先写好抓取数据的shell 脚本 并在现象发生时及时按下回车键

Ⅸ 数据库的数据传输过慢怎么办

说明你们半天有人在办公室占速

Ⅹ 远程连接数据库太慢怎么办

远程数据库连接特别慢
怎么办
首先确认什么操作最消耗时间。
是数据查询，还是服务器之间的传输。
如果查询慢，需要根据你实际的数据模型优化sql，增加索引。具体操作网络。
如果传输慢，想办法把几十次请求放到一次请求里面完成，减少服务器之间的交互。