MySQL数据库中一个表A, 频繁的进行插入更新 *** 作, 我想知道对A进行查询读取是否会受到影响

肯定是有影响的，因为在插入，更新，查询时，MySQL都会有一个锁 *** 作这个是隐形的，看不到，也可以理解为一个时间结点，每一个 *** 作都有一个时间结点，你在查询时同时写入，那MySQL就不知道你有没有写入或更新，此时，MySQL会在锁定的形式，暂时将程序锁定一个状态，然后查询，之后在解锁。这样才能保证查询不出错。以上只是理论的解释。

同时还有一种IO *** 作的时效，每一个插入，更新或查询都是一个IO写和读的过程，资源是固定的，你不断的更新或插入，查询IO的时间肯定会被拉长，这样的话，就影响到了你的效率。

以上为个人见解，希望对你有帮助。

如何优化 *** 作大数据量数据库

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

1．合理使用索引

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

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

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

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

●如果待排序的列有多个，可以在这些列上建立复合索引（pound 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 custname，rcvblesbalance，……other columns

FROM cust，rcvbles

WHERE custcustomer_id = rcvlbescustomer_id

AND rcvbllsbalance>0

AND custpostcode>“98000”

ORDER BY custname

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

SELECT custname，rcvblesbalance，……other columns

FROM cust，rcvbles

WHERE custcustomer_id = rcvlbescustomer_id

AND rcvbllsbalance>0

ORDER BY custname

INTO TEMP cust_with_balance

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

SELECT ＊ FROM cust_with_balance

WHERE postcode>“98000”

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

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

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

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

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

实例分析

下面我们举一个制造公司的例子来说明如何进行查询优化。制造公司数据库中包括3个表，模式如下所示：

1．part表

零件号零件描述其他列

（part_num）（part_desc）（other column）

102，032Seageat 30G disk……

500，049Novel 10M neork card……

……

2．vendor表

厂商号厂商名其他列

（vendor _num）（vendor_name） （other column）

910，257Seageat Corp……

523，045IBM Corp……

……

3．parven表

零件号厂商号零件数量

（part_num）（vendor_num）（part_amount）

102，032910，2573,450,000

234，423321，0014，000，000

……

下面的查询将在这些表上定期运行，并产生关于所有零件数量的报表：

SELECT part_desc，vendor_name，part_amount

FROM part，vendor，parven

WHERE partpart_num=parvenpart_num

AND parvenvendor_num = vendorvendor_num

ORDER BY partpart_num

如果不建立索引，上述查询代码的开销将十分巨大。为此，我们在零件号和厂商号上建立索引。索引的建立避免了在嵌套中反复扫描。关于表与索引的统计信息如下：

表行尺寸行数量每页行数量数据页数量

（table）(row size)（Row count）（Rows/Pages）（Data Pages）

part15010，00025400

Vendor1501，000 2540

Parven13 15，000300 50

索引键尺寸每页键数量页面数量

（Indexes）(Key Size)（Keys/Page)(Leaf Pages）

part450020

Vendor45002

Parven825060

看起来是个相对简单的3表连接，但是其查询开销是很大的。通过查看系统表可以看到，在part_num上和vendor_num上有簇索引，因此索引是按照物理顺序存放的。parven表没有特定的存放次序。这些表的大小说明从缓冲页中非顺序存取的成功率很小。此语句的优化查询规划是：首先从part中顺序读取400页，然后再对parven表非顺序存取1万次，每次2页（一个索引页、一个数据页），总计2万个磁盘页，最后对vendor表非顺序存取15万次，合3万个磁盘页。可以看出在这个索引好的连接上花费的磁盘存取为504万次。

hibernate如何优化大数据量 *** 作？

建议你直接用Jdbc好了，用batch，这样是最快的。

如何实现大数据量数据库的历史数据归档

打开数据库

conOpen();

读取数据

OdbcDataReader reader = cmdExecuteReader();

把数据加载到临时表

dtLoad(reader);

在使用完毕之后，一定要关闭，要不然会出问题

readerClose();

这个问题是这样的：

首先你要明确你的插入是正常业务需求么？如果是，那么只能接受这样的数据插入量。

其次你说数据库存不下了 那么你可以让你的数据库上限变大 这个你可以在数据库里面设置的 里面有个数据库文件属性 maxsize

最后有个方法可以使用，如果你的历史数据不会对目前业务造成很大影响 可以考虑归档处理 定时将不用的数据移入历史表 或者另外一个数据库。

注意平时对数据库的维护 定期整理索引碎片

时间维度分区表，然后定情按照规则将属于历史的分区数据迁移到，历史库上，写个存储自动维护分区表。

如何用java jdbc 向数据库表插入大数据量

一次性插入大量数据，只能使用循环，

如：游标，while 循环语句

下面介绍While 循环插入数据，

SQL 代码如下：

IF OBJECT_ID('dboNums') IS NOT NULL

DROP TABLE dboNums;

GO

CREATE TABLE dboNums(n INT NOT NULL PRIMARY KEY);

DECLARE @max AS INT, @rc AS INT;

SET @max = 5000000;

SET @rc = 1;

INSERT INTO Nums VALUES(1);

WHILE @rc 2 <= @max

BEGIN

INSERT INTO dboNums SELECT n + @rc FROM dboNums;

SET @rc = @rc 2;

END

INSERT INTO dboNums SELECT n + @rc FROM dboNums WHERE n + @rc <= @max;

--以上函数取自Inside SQL Server 2005: T-SQL Query一书。

INSERT dboSample SELECT n, RAND(CAST(NEWID() AS BINARY(16))) FROM Nums

php 怎么解决 大数据量 插入数据库

ini_set('max_execution_time','0');

$pdo = new PDO("mysql:host=localhost;dbname=test","root","123456");

$sql = "insert into test(name,age,state,created_time) values";

for($i=0; $i<100000; $i++){

$sql ="('zhangsan',21,1,'2015-09-17')";

}

$sql = substr($sql,0,strlen($sql)-1);

var_dump($sql);

if($pdo -> exec($sql)){

echo "插入成功！";

echo $pdo -> lastinsertid();

}

试试吧。10万条1分钟多，我觉得还行

请教如何通过WCF传输大数据量数据

就是直接把DataSet 类型作为参数直接传递给服务端

WCF默认支持这么做，直接传Datatable不行。

你看一下 “服务引用设置”中你选的 类型是什么，我选的是SystemArray

字典 类型是默认第一项 SystemCollectionsGenericDictionary

又是一个把自己架在火上烤的需求啊，

如果不考虑传输因素，可以调整wcf配置，提升传递的容量，如果是对象传递可能还要调整对象层次的深度

1

sql

数据库占用磁盘IO读写过高，

2

原因：可能是插入数据频繁，并且存在的索引太多

3

所以建议清除不用的索引

4

或是对数据库进行重建索引

5

也可以叫DBCC

*** 作

有客户遇到SQL性能不稳定 突然变差导致系统性能出现严重问题的情况 对于大型的系统来说 SQL性能不稳定 有时突然变差 这是常常遇到的问题 这也是一些DBA的挑战

对于使用Oracle数据库的应用系统 有时会出现运行得好好的SQL 性能突然变差 特别是对于OLTP类型系统执行频繁的核心SQL 如果出现性能问题 通常会影响整个数据库的性能 进而影响整个系统的正常运行 对于个别的SQL 比如较少使用的查询报表之类的SQL 如果出现问题 通常只影响少部分功能模块 而不会影响整个系统

那么应该怎么样保持SQL性能的稳定性？

SQL的性能变差 通常是在SQL语句重新进行了解析 解析时使用了错误的执行计划出现的 下列情况是SQL会重新解析的原因

SQL语句没有使用绑定变量 这样SQL每次执行都要解析

SQL长时间没有执行 被刷出SHARED POOL 再次执行时需要重新解析

在SQL引用的对象（表 视图等）上执行了DDL *** 作 甚至是结构发生了变化 比如建了一个索引

对SQL引用的对象进行了权限更改

重新分析（收集统计信息）了SQL引用的表和索引 或者表和索引统计信息被删除

修改了与性能相关的部分参数

刷新了共享池

当然重启数据库也会使所有SQL全部重新解析

SQL重新解析后 跟以前相比 性能突然变差 通常是下列原因

表和索引的优化统计信息被删除 或者重新收集后统计信息不准确 重新收集统计信息通常是由于收集策略（方法）不正确引起 比如对分区表使用 yze命令而不是用dbms_stats包 收集统计信息时采样比例过小等等 Oracle优化器严重依赖于统计信息 如果统计信息有问题 则很容易导致SQL不能使用正确的执行计划

SQL绑定变量窥探(bind peeking) 同时绑定变量对应的列上有直方图 或者绑定变量的值变化范围过大 分区数据分布极不均匀

） 绑定变量的列上有直方图

假如表orders存储所有的订单 state列有 种不同的值 表示未处理 表示处理成功完成 表示处理失败 State列上有一个索引 表中绝大部分数据的state列为 和 占少数 有下面的SQL

select from orders where state=:b

这里:b 是变量 在大多数情况下这个值为 则应该使用索引 但是如果SQL被重新解析 而第一次执行时应用传给变量b 值为 则不会使用索引 采用全表扫描的方式来访问表 对于绑定变量的SQL 只在第一次执行时才会进行绑定变量窥探 并以此确定执行计划 该SQL后续执行时全部按这个执行计划 这样在后续执行时 b 变量传入的值为 的时候 仍然是第一次执行时产生的执行计划 即使用的是全表扫描 这样会导致性能很差

） 绑定变量的值变化范围过大

同样假如orders表有一列created_date表示一笔订单的下单时间 orders表里面存储了最近 年的数据 有如下的SQL

Select from orders where created_date >=:b ;

假如大多数情况下 应用传入的b 变量值为最近几天内的日期值 那么SQL使用的是created_date列上的索引 而如果b 变量值为 个月之前的一个值 那么就会使用全表扫描 与上面描述的直方图引起的问题一样 如果SQL第 次执行时传入的变量值引起的是全表扫描 那么将该SQL后续执行时都使用了全表扫描 从而影响了性能

） 分区数据量不均匀

对于范围和列表分区 可能存在各个分区之间数据量极不均匀的情况下 比如分区表orders按地区area进行了分区 P 分区只有几千行 而P 分区有 万行数据 同时假如有一列product_id 其上有一个本地分区索引 有如下的SQL

select from orders where area=:b and product_id =:b

这条SQL由于有area条件 因此会使用分区排除 如果第 次执行时应用传给b 变量的值正好落在P 分区上 很可能导致SQL采用全表扫描访问 如前面所描述的 导致SQL后续执行时全部使用了全表扫描

其他原因 比如表做了类似于MOVE *** 作之后 索引不可用 对索引进行了更改 当然这种情况是属于维护不当引起的问题 不在本文讨论的范围

综上所述 SQL语句性能突然变差 主要是因为绑定变量和统计信息的原因 注意这里只讨论了突然变差的情况 而对于由于数据量和业务量的增加性能逐步变差的情况不讨论

为保持SQL性能或者说是执行计划的稳定性 需要从以下几个方面着手

规划好优化统计信息的收集策略 对于Oracle g来说 默认的策略能够满足大部分需求 但是默认的收集策略会过多地收集列上的直方图 由于绑定变量与直方图固有的矛盾 为保持性能稳定 对使用绑定变量的列 不收集列上的直方图 对的确需要收集直方图的列 在SQL中该列上的条件就不要用绑定变量 统计信息收集策略 可以考虑对大部分表 使用系统默认的收集策略 而对于有问题的 可以用DBMS_STATS LOCK_STATS锁定表的统计信息 避免系统自动收集该表的统计信息 然后编写脚本来定制地收集表的统计信息 脚本中类似如下

exec dbms_stats unlock_table_stats…

exec dbms_stats gather_table_stats…

exec dbms_stats lock_table_stats…

修改SQL语句 使用HINT 使SQL语句按HINT指定的执行计划进行执行 这需要修改应用 同时需要逐条SQL语句进行 加上测试和发布 时间较长 成本较高 风险也较大

修改隐含参数 _optim_peek_user_binds 为FALSE 修改这个参数可能会引起性能问题（这里讨论的是稳定性问题）

使用OUTLINE 对于曾经出现过执行计划突然变差的SQL语句 可以使用OUTLINE来加固其执行计划 在 g中DBMS_OUTLN CREATE_OUTLINE可以根据已有的执行正常的SQL游标来创建OUTLINE 如果事先对所有频繁执行的核心SQL使用OUTLINE加固执行计划 将最大可能地避免SQL语句性能突然变差

注 DBMS_OUTLN可以通过$ORACLE_HOME/rdbms/admin/dbmsol sql脚本来安装

使用SQL Profile SQL Profile是Oracle g之后的新功能 此处不再介绍 请参考相应的文档

除此之外 可以调整一些参数避免潜在的问题 比如将 _btree_bitmap_plans 参数设置为FALSE（这个参数请参考互联网上的文章或Oracle文档）

lishixinzhi/Article/program/Oracle/201311/18054

当初淘宝从mysql转到oracle时用的是一个连接池，把数据分了模块，你可以借鉴一下，如果现在就有百万数据的话，就最好早些转移到oracle，数据增长很迅速，而且一直用mysql对于以后的数据分析与挖掘肯定不太方便，你可以看看淘宝的数据发展史。。。>

以上就是关于MySQL数据库中一个表A, 频繁的进行插入更新 *** 作, 我想知道对A进行查询读取是否会受到影响全部的内容，包括:MySQL数据库中一个表A, 频繁的进行插入更新 *** 作, 我想知道对A进行查询读取是否会受到影响、如何优化 *** 作大数据量数据库、主机sql数据库占用磁盘IO读写过高,怎么解决等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！