mysql卡怎么解决 mysql特别慢

求助 安装mysql卡在了 starting server我今天也卡在这上面了,最后我终于解决了,首先确保(如果这台电脑之前有安装)你把先前sql的卸载完,去安装的盘搜索mysql/MySQL和注册表(编辑再查找mysql/MySQL)和控制面板的程序那里一个一个删,呜呜呜,我是去服务那里找MySQL80 , 发现这个服务已停止,启动也启动不了,你们可以去找下相关网址 , 我找到这个网址关于如何启动这个服务 , 就是右键MySQL,然后点属性 , 然后点登录,把这个此账户改为.\administrator然后输入管理员的密码,你可以先设置管理员账户的密码,再弄这个,弄完这个再启动就可以启动了 , 我就是这个解决的,之后那个starting server终于通过了
mysql数据量上十万条后,查询慢导致服务器卡有什么解决办法几方面:
硬件,软件,以及语言
硬件,是不是抗不住,
软件,mysql是不是没有设置好,数据库设计方面等,
语言,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 '李%'若要提高效率,可以考虑全文检索 。
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 name like 'abc%'
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.尽量避免向客户端返回大数据量 , 若数据量过大,应该考虑相应需求是否合理 。
mysql服务卡在启动状态看下你mysql卡怎么解决的my.ini配置有没有遗漏(看仔细点),mysql卡怎么解决我的就是第一行少了[mysql] 。
确定了配置文件的问题后,先重新卸载,cmd模式下到bin目录走下mysqld -remove
下面就是重新安装了再启动应该就是可以了 。
总的来说就是因为配置文件不对,重新安装下就行了
mysql千万数据加索引卡死关键字mysql千万数据加索引卡死关键字?
想到了从以下方法进行解决:
1)重写Sql , 让查询命中索引
2)增加索引
3)1)或者2)方法之后,再加上一个缓存功能
最快捷的方式肯定是2了,但是本表由于逻辑复杂 , 时不时又批量录入一些数据,已经有了5个索引了,再加索引,恐怕会导致写入慢的问题,而且加索引可能会引起锁表问题 。
于是 , 我先想用方法1解决,可是由于逻辑有点复杂,查询语句比较复杂 , 改了很多写法都不理想,最后还是选择了方法2 , 直接表加索引 。
由于对于加索引的一些担忧,于是我在本地先尝试了一下(本地数据和线上数据量基本一致,相差不大) , 结果没想到还挺快的,对于写入的性能也没多大的影响 。加入索引后页面秒开,效果很好 。
CentOS7重启后mysql无法启动怎么办,不是报错就是卡死一、my.cnf配置文件datadir项配置错误或被启动脚本篡改
这个问题不太说讲mysql卡怎么解决 , 主要是mysql自带的启动文件(/etc/init.d/mysqld)中会自动检测mysql的数据存储目录,若mysql新装,尚未初始化系统表 , 那么配置文件中的datadir项写不写无所谓,出现这种情况主要是在更改了mysql的数据存储目录,今天我出现的这个问题就在于此 。
我的mysql安装后的配置文件中关于datadir项目的配置如下,而该配置文件存储于/etc/my.cnf,今儿不知动了什么东西 , 查来查去都没找着原因,后来打开该配置文件才发现,其中的datadir项目被篡改成/var/mysql/data了.....
[mysqld] datadir=/data/mysql socket=/tmp/mysql.sock user=mysql
二、进程里已经存在mysql进程
这种情况我很少遇到,若存在mysql进程但有不提供mysql服务(表现为其他客户端连接不上mysql服务器,例如php连接mysql时提示“连接失败”),这个时候就要看看有没有存在的mysql僵尸进程了,命令如下:
ps -ef|grep mysql
若存在 , 该命令执行后会列出存在的僵尸进程,kill -9 `pid`掉即可 。
三、mysql的数据存储目录权限不足
这种情况发生于mysql第一次安装或升级,配置文件中的datatdir目录的权限要设定好,一般来说运行mysql的用户以及组就是mysql.mysql,那么解决权限不足问题的方法如下:
chown -R mysql.mysql /data/mysql ##该命令仅为示例 , 其中/data/mysql就是mysql配置文件中datadir的目录 ##若为空,则默认为mysql安装目录下的data文件夹下
四、覆盖安装或升级mysql后 , 残余数据的影响
这种情况发生于mysql被覆盖安装或升级后,当然mysql无故宕机后也会有这种情况,可能会影响mysql启动的数据文件 , 一般存在于mysql的数据存储目录(这个目录依据my.cnf配置文件中的datadir而异),也就是存在于mysql数据存储目录下的mysql-bin.index文件,删除之即可 。
五、selinux的问题,centos下最容易出现
selinux不甚了解,直接关掉 。
【mysql卡怎么解决 mysql特别慢】##方法1:永久关闭seliux ##修改 vi /etc/selinux/config #文件中设置SELINUX=disabled ,然后重启服务器 ##方法2:暂时关闭seliux setenforce 0 ##如需每次开机都铃声关闭seliux,则可以在/etc/rc.d/rc.local文件中添加该命令
六、mysql运行状态下删除binary日志后重启失败
这是今天在群里的一个朋友出现的 , 特汇总于此mysql卡怎么解决;当mysql开启了二进制日志并且mysql在运行状态下用rm命令删除过mysql的binary日志文件的话,下次重启mysql你就悲剧了 。
什么是binary日志mysql卡怎么解决?说白了就是mysql的数据目录下的mysql-bin.000001、mysql-bin.000002的文件,下图所示 。
解决方法就是修改配置文件临时关闭binary-log,然后删除mysql数据目录下的所有类似mysql-bin.000001、mysql-bin.000002的文件后再次重启,mysql即可启动成功 。
#mysql配置关闭二进制日志 找到如下语句 注释掉即可 #log-bin=mysql-bin #binlog_format=mixed
此步骤操作完毕之后,若还需要启用二进制日志 , 那么就要先停掉mysql服务,然后修改msyql的配置文件,再次重启即可 。
另外再附上正确删除mysql二进制日志文件的方法(绝对不是rm -rf命令直接删这些文件):
#第一步 通过shell或cmd登录进mysql 这步没什么好说的 msyql -u root -p *** #第二步 在mysql下直接执行清理binary日志命令 mysql reset master #注意:此处仅针对单台mysql而言,若有互备mysql 则执行该命令有风险
mysql操作中卡死 解决方法show full processlist; -- 查询全部当前进程;
show processlist;-- 只列出前100条
kill 99; -- 99为卡死id
show status;
mysql卡怎么解决的介绍就聊到这里吧,感谢你花时间阅读本站内容 , 更多关于mysql特别慢、mysql卡怎么解决的信息别忘了在本站进行查找喔 。

    推荐阅读