一直很喜欢Mysql的路过:victory:
回复 1# cnlnzz01
1.如果是你，你怎么处理慢查询引起的问题，并且在以后避免这种情况发生？
这个问题要解决的话问题就在研发的了，最好上sql 审计的话可以避免问题
2.除了慢查询，还有哪些情况会导致MySQL卡顿，查询较慢？
这个主要有很多主要还是跟调优方面的分类差不多
硬件征用： 内存cpu io网络
配置方面内存分配不合理主机参数
sql 设计： sql 的锁 大的sql抢占资源等
3.针对于数据库优化，您有哪些比较实用的建议和想法？
其实调优的话还是调整平衡看你得消耗了调整好 内核参数配置文件 等
4.结合生产环境，您觉得MySQL，较于PG NOsql DB2 Sybase MongoDB Oracle等数据库来，他的优点在哪？在什么情况下你会使用其它类型的DB
其实选择的话没有什么最合适的。还是看业务吧
交易系统还是适合oracle
展示等系统 适合mysql
redis memcached 做缓存
mongodb适合分析
没有绝对的还是看你用什么用的最好把，有时候用的好的话 还是可以省事好多
5.如果您是数据库的设计者，您会去怎么设计数据库的引擎和结构？
基本上mysql innodb 存储引擎为主表必须主键最好是自增的id 剩下出查询的索引 就好了
不会，拿起小板凳围观{:yxh110:}
1. 如果是你，你怎么处理慢查询引起的问题，并且在以后避免这种情况发生？
==>对于这种情况，运维是应该监控，并提前知道的，通过show full processlist;对于什么用用户（User）从哪台主机（Host）来在哪个库（db）上所执行的sql语句运行的状态（Command），该sql运行超过了设定的时间（Time）进行告警.
2. 除了慢查询，还有哪些情况会导致MySQL卡顿，查询较慢？
==>禁用DNS反向解析，OS以外的，就用1来监控
3. 针对于数据库优化，您有哪些比较实用的建议和想法？
==>数据库的优化，DBA首先要对业务逻辑很熟悉，要在设计阶段进行把控，数据类型尽量精准，尽量避免锁竞争、死锁（尽可能的避免gap)的情况产生，索引要定期的进行检查，检查是否合理，是否达到了最优.
4. 结合生产环境，您觉得 MySQL，较于PG NOsql DB2 Sybase MongoDB Oracle等数据库来，他的优点在哪？在什么情况下你会使用其它类型的DB
===》只对Mysql有研究，其他不太熟悉，目前mysql在我们生产环境中用于交易系统（外汇、二元期权、P2P等）此处关于外汇系统，由于汇率tick数据量巨大（接收7家银行、30个货币对一周3亿条数据），后台检索比较麻烦，只能定期进行处理，此处感觉不足.
5. 如果您是数据库的设计者，您会去怎么设计数据库的引擎和结构？
===>我首先会去花大量的时间去熟悉业务逻辑，然后根据业务需要进行设计，要让开发者完全认同你的设计.
这本书其实还不错，看完就会觉得不那么高大上，哎，慢慢学，不要着急啊。{:1_1:}
本帖最后由 cjfeii 于 2015-12-14 11:54 编辑
1.如果是你，你怎么处理慢查询引起的问题，并且在以后避免这种情况发生？
如果确定是由于慢查询引起的MySQL数据库性能问题，首先通过“show processlist”以及“slow.log”确定具体哪些慢查询，确定之后根据慢查询不同的情况去优化：
1. 如果是SQL有问题，那么就优化SQL；
2. 优化之后的SQL，可以通过添加索引来提升查询性能，但是，添加索引是一把双刃剑：会降低“insert/update”的性能，并且还要占用额外的存储空间，所以谨慎的对待添加索引；
3. 如果添加索引不能很好的提高性能，那么可以根据数据的读写特点以及数据规模去选择合适的存储引擎，虽然在目前innodb引擎性能很好，支持事务，用的也很广泛，但是也不要忽视其他的存储引擎的优势，比如TokuDB的高压缩比以及高insert属性等；
4. 如果数据规模超出了单机MySQL存储容量范围，那么就需要扩展机器做集群或者替换MySQL数据库寻求更适合的存储数据库；
2.除了慢查询，还有哪些情况会导致MySQL卡顿，查询较慢？
引起MySQL卡顿的情况有很多，但是根本原因主要就是CPU以及IO的抢占。比如：
1. 大规模的写会占用大量的IO资源会引起MySQL卡顿；
2. 如果MySQL所在的服务器上运行着其他的应用程序，并占用太多的CPU或是IO，那么也会导致MySQL查询较慢；
3. 等等。
生产环境永远是最复杂的系统，线上MySQL卡顿也会有多种原因，这就使得掌握查找卡顿原因的方法尤为重要，如：show processlist，top/htop，iostat/iotop，strace等（）。
3.针对于数据库优化，您有哪些比较实用的建议和想法？
数据库优化不是一朝一夕就能做好，在平时的工作中要一点一滴的来做，不同部门协同来做：
1. 数据库设计的时候：合理设计表结构以及合理访问数据库表；
2. 数据库运行过程中，注意性能的监控，最直观的就是：slowlog和show processlist，还需要注意其他指标的波动（disk, io, net等）；
3. 优化的时候，要全盘考虑，避免只考虑将来而忘掉过去（程序员会发疯的）；
4. 等等。
4.结合生产环境，您觉得MySQL，较于PG NOsql DB2 Sybase MongoDB Oracle等数据库来，他的优点在哪？在什么情况下你会使用其它类型的DB
相对于其他关系型数据库，主要就是：社区比较活跃，软件更新快，从业人员比较多，还有就是免费。
和nosql数据库相比，就是：支持事务，复杂的sql，稳定。
具体选用哪种DB，主要有三个因素——业务数据特点、DB的成熟度、团队的技术栈。比较主流的SQL+NOSQL就是：MySQL+Redis等。
5.如果您是数据库的设计者，您会去怎么设计数据库的引擎和结构？
主要看对数据库的定位，不同的定位导致不同的底层设计（引擎和结构），如果侧重点是事务型，那么就是MySQL、PG的设计等，非事务的话可以考虑nosql的存储模式（Log Structured Merge等）。
我说一个我自己工作中用到的场景：
有一个特别大的表，这个表用于保存终端上传的数据，只增加不修改，并主要承载一些查询业务（主要是范围查找），目前这张表的存储引擎是innodb。其实不管是事务型的innodb还是非事务型的MyISAM，底层都是B-树或是B+树的存储结构（其他大部分数据库系统也是这样），都是平衡树，写的过程中总会有blance的时候，而且会导致逻辑上相邻的数据在物理上不相邻，在范围访问的过程中会造成很多的随机IO，使得性能有所降低，针对这样的情况有没有更好的存储方式呢？
抛砖引玉：待后者续。。。
遇到慢查询就想办法绕过去，特别是那些join了一大堆的sql语句，必须绕过去才行，否则卡住整个数据库都不是困难的事，虽然原理上来说join效率应该不低，但有时候还真不如把sql拆分，然后再语言（PHP）上来解决。
回复 1# cnlnzz01
之前我用inforbright ，也曾常出现这样情况，通常是内存耗完后发生。
本帖最后由 ghostwwl 于 2015-12-14 17:57 编辑
1. 开慢查询日志
2. 记得没错的话 应该可以记录所有没有使用索引的语句
3. 根据日志做具体处理
4. innodb 最好每张表 单独表空间
5. 看mysql的状态值 相关配置该调整的调整
有了一少年宫结果慢慢处理
如果结构索引没问题 量大的表 分表才是硬道理
然后 sar ionice iostat 之类 看是否硬件瓶颈