1. 如何解决mysql 查询和更新速度慢
索引是快速搜索的关键。MySQL索引的建立对于mysql的高效运行是很重要的。下面几种常见的MySQL索引类型。
在数据库表中，对字段建立索引可以大大提高查询速度。假如我们创建了一个 mytable表：
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL ); 我们随机向里面插入了10000条记录，其中有一条：5555,admin。
在查找username="admin"的记录 SELECT * FROMmytable WHERE username='admin';时，如果在username上已经建立了索引，MySQL无须任何扫描，即准确可找到该记录。相反，MySQL会扫描所有记录，即要查询10000条记录。
索引分单列索引和组合索引。单列索引，即一个索引只包含单个列，一个表可以有多个单列索引，但这不是组合索引。组合索引，即一个索包含多个列。
MySQL索引类型包括：
（1）普通索引
这是最基本的索引，它没有任何限制。它有以下几种创建方式：
◆创建索引
CREATE INDEX indexName ONmytable(username(length)); 如果是CHAR，VARCHAR类型，length可以小于字段实际长度；如果是BLOB和TEXT类型，必须指定 length，下同。
◆修改表结构
ALTER mytable ADD INDEX [indexName] ON(username(length)) ◆创建表的时候直接指定
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, INDEX [indexName] (username(length)) ); 删除索引的语法：
DROP INDEX [indexName] ON mytable;
（2）唯一索引
它与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。它有以下几种创建方式：
◆创建索引
CREATE UNIQUE INDEX indexName ONmytable(username(length)) ◆修改表结构
ALTER mytable ADD UNIQUE [indexName] ON(username(length)) ◆创建表的时候直接指定
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, UNIQUE [indexName] (username(length)) );
（3）主键索引
它是一种特殊的唯一索引，不允许有空值。一般是在建表的时候同时创建主键索引：
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, PRIMARY KEY(ID) ); 当然也可以用 ALTER 命令。记住：一个表只能有一个主键。
（4）组合索引
为了形象地对比单列索引和组合索引，为表添加多个字段：
CREATE TABLE mytable( ID INT NOT NULL, username VARCHAR(16) NOT NULL, city VARCHAR(50) NOT NULL, age INT NOT NULL ); 为了进一步榨取MySQL的效率，就要考虑建立组合索引。就是将 name, city, age建到一个索引里：
ALTER TABLE mytable ADD INDEX name_city_age(name(10),city,age); 建表时，usernname长度为 16，这里用 10。这是因为一般情况下名字的长度不会超过10，这样会加速索引查询速度，还会减少索引文件的大小，提高INSERT的更新速度。
2. DB2数据库更新数据缓慢，求优化建议
你这样写很不好，看起来写的是一句sql，反而速度慢下来了。首先row_number() over() as rownum毫无必要，这样来分页效率不高。然后能不用*就不用*查询。在大数据量和列很多的情况下，会慢很多。
而且你也说了，更新1W条数据需要半个小时。那么可以采用存储过程或者程序来访问。这样会快很多，推荐采用存储过程，110W条数据，就算重建索引等，更新一条应该在200ms一下，一万条，不会那么久的。希望能帮助得到你。
你这样写sql语句，执行时间太久了，会造成假死现象，这样很不好。
3. 数据库插入数据或更新数据的时候反应很慢，怎么优化
查询速度慢，跟你的插入没多大关系
大表sdy_db_testb的C_testa字段建索引；
把select a.*,b.c_xname from sdy_db_testb a left join sdy_db_testc b on 1=1 and b.c_testa=a.c_testa改成
select a.*,b.c_xname from sdy_db_testc a left join sdy_db_testb b on 1=1 and b.c_testa=a.c_testa;
即左边的为小表，这样就快 了；
不知道你的需求是否要把大表的数据都取出来
如果是都需要取出来的话，慢是必然的！因为要读的块数无法减少，IO开销你怎么优化都是无用的
4. 用PB开发的一个数据库服务器多个异地客户端使用查询更新速度慢问题解决的技术方法
处理的方法很简单：
1、并不是所有的地方都需要使用read commit的加锁级别，你从application中设置一句sqlca.lock="RU", 使用脏读，这样就可以去掉大多数不必要的SELECT行锁。然后在一定要读最新数据的地方，把SQLCA。LOCK改为RC，用完后再改回来。
这样就避免了几乎80%的阻塞。
2、对于由于行更新，或者其他UPDATE导致的锁，一般数据库会自己协调，在事务比较长的情况下，这需要你对原来的程序做适当的修改。把长事务变为几个小的事务，在事务中做更新操作，不要插入用户的交互。这是系统的设计原则。
如果你的系统对事务的要求不严格，又不想改动原来的程序，办法更简单，在前面
SQLCA。LOCK的基础上，加句SQLCA。AUTOCOMMIT=TRUE，这样每数据修改自动提交，就可以避免大多数由于更新产生的死锁和阻塞。
3、最后要对付的是刚才说的被大量应用频繁访问的表（HOT TABLE），如果你的系统允许使用RU加锁级别，那么不用太考虑，因为SELECT已经不会导致锁定了。
但是如果你不能使用RU方式（1里头提到的办法），
那么要采用这样的手段：
使用索引把更新锁，SELECT锁来分开，同时也避免SQLSERVER傻傻为了性能的原因把行锁升级为表锁。
具体办法是建立一个索引，如果可以的话使用聚集索引，因为聚集索引采用的是类似HASH的检索方式，这样当查找索引的时候，就不需要访问数据表了。
另一种办法，是将你SELECT语句中要检索的数据都加到索引中，例如你检索NAME，SEX，AGE，如果你把三个数据都加入了索引，这就意味着SELECT语句只要找到索引，就已经找到了最后要选取的数据（从索引中），这样自然不会去LOCK表了。这样做的时候要针对你的程序仔细选择索引，否则把索引变成了表的一个备份就没有意义了。
5. 数据库大量数据update慢，如何克服
用的是单机数据库吗？ 如果数据量过大性能可能无法支撑，可以尝试改用分布式数据库。
相对于单机数据库，分布式数据库的数据分布式存储，读写分离，性能高，在线一键平滑扩容，感兴趣可以了解一下。
顺便给个福利，华为云分布式数据库中间件DDM正在做试用体验活动，可以了解一下。
6. 怎么样解决数据库中的数据量比较大时访问慢的问题
数据量比较大的访问速度慢问题，就目前来说，我遇到的解决方法有一些，首先尽量不使用select *，因为数据库在进行查询时会把*对应的列进行解析，会使得数据库的访问速度变慢，查询时应该选择需要的列；另外在查询时需要在关键列上建立索引，索引是提高访问数据库速度的最重要的手段，一般访问速度慢的问题中，90%可以使用建立索引来解决，具体怎么建立索引还请楼主自己查看相关资料；再一个就是及时对表进行数据分析，分析过的表能够自己选择合适的索引，使得查询性能在一定程度上得到提高（但是数据库自己选择的执行路径也不一定都是正确的，这一点需要具体问题具体分析）。
7. 如何解决mysql 查询和更新速度慢
问题
我们有一个 SQL，用于找到没有主键 / 唯一键的表，但是在 MySQL 5.7 上运行特别慢，怎么办?
实验
我们搭建一个 MySQL 5.7 的环境，此处省略搭建步骤。
写个简单的脚本，制造一批带主键和不带主键的表：
可以看到执行时间变成了 0.67s。
整理
我们诊断的关键点如下：
1. 对于 information_schema 中的元数据表，执行计划不能提供有效信息。
2. 通过查看 MySQL 改写后的 SQL，我们猜测了优化器发生了误判。
3. 我们增加了 hint，指导 MySQL 正确进行优化判断。
但目前我们的实验仅限于猜测，猜中了万事大吉，猜不中就无法做出好的诊断。
8. MySQL数据库服务器逐渐变慢分析与解决方法分享
一、检查系统的状态
通过操作系统的一些工具检查系统的状态，比如CPU、内存、交换、磁盘的利用率，根据经验或与系统正常时的状态相比对，有时系统表面上看起来看空闲，这也可能不是一个正常的状态，因为cpu可能正等待IO的完成。除此之外，还应观注那些占用系统资源(cpu、内存)的进程。
1.使用sar来检查操作系统是否存在IO问题
#sar-u210—
即每隔2秒检察一次，共执行20次。
结果示例：
注：在redhat下，%system就是所谓的%wio。
Linux2.4.21-20.ELsmp
(YY075)05/19/2005
10:36:07AMCPU%user%nice%system%idle
10:36:09AMall0.000.000.1399.87
10:36:11AMall0.000.000.00100.00
10:36:13AMall0.250.000.2599.49
10:36:15AMall0.130.000.1399.75
10:36:17AMall0.000.000.00100.00
其中：
%usr指的是用户进程使用的cpu资源的百分比;
%sys指的是系统资源使用cpu资源的百分比;
%wio指的是等待io完成的百分比，这是值得观注的一项;
%idle即空闲的百分比。
如果wio列的值很大，如在35%以上，说明系统的IO存在瓶颈，CPU花费了很大的时间去等待I/O的完成。Idle很小说明系统CPU很忙。像以上的示例，可以看到wio平均值为11，说明I/O没什么特别的问题，而idle值为零，说明cpu已经满负荷运行了。
2.使用vmstat监控内存
cpu资源
[root@mysql1
~]#
vmstat
procs
———–memory———-—swap–
—–io—-–system–
—–cpu——
r
b
swpd
free
buff
cache
si
so
bi
bo
in
cs
us
sy
id
wa
st
0
0
72
25428
54712672264
0
0
14
43
53
59
1
198
0
0
vmstat
的输出那些信息值得关注?
io
bo:
磁盘写的数据量稍大，如果是大文件的写，10M以内基本不用担心，如果是小文件写2M以内基本正常
①
CPU问题
下面几列需要被察看，以确定cpu是否有问题
Processesinthe
run
queue
(procs
r)
Usertime
(cpu
us)
System
time
(cpu
sy)
Idle
time
(cpu
id)
问题情况:
如果processes
in
run
queue
(procs
r)的数量远大于系统中cpu的数量，将会使系统便慢。
如果这个数量是cpu的4倍的话，说明系统正面临cpu能力短缺,这将使系统运行速度大幅度降低
如果cpu的idle时间经常为0的话，或者系统占用时间(cpu
sy)是用户占用时间(cpu
us)两辈的话，系统面临缺少cpu资源
解决方案
:
解决这些情况，涉及到调整应用程序，使其能更有效的使用cpu，同时增加cpu的能力或数量
②内存问题
主要查看页导入的数值(swap中的si)，如果该值比较大就要考虑内存，大概方法如下：
最简单的，加大RAM
减少RAM的需求
3.磁盘IO问题
处理方式：做raid10提高性能
4.网络问题
telnet一下MySQL对外开放的端口，如果不通的话，看看防火墙是否正确设置了。另外，看看MySQL是不是开启了skip-networking的选项，如果开启请关闭。