需求获取一般包括这几种方式： 观察法、体验法、问卷调查法、访谈法、单据分析法、报表分析法、需求调研会法。这是需求调研的“七种武器”，它们各有优缺点，无论你想要了解的是什么需求，都需要将这些方式组合应用，针对你想要了解的内容，以及需要了解的对象的工作特点，采用不同的方式。学会并坚持使用这七种武器后，我想你很快就会成为需求调研的真正高手。 观察法 观察法，就是你自己跑到工作现场，看！这个看上去相当简单，貌似走马观花，有些不在行的兄弟会弄得跟公费旅游一般，车间里走走散散心，撩撩HR妹子，就认为是观察法调研了，其实不然。这种方法，关键是要看人家是怎么工作的，拿了什么，干了什么，用了什么工具，送出去什么，什么时候填写了什么单据，制作了什么报表，等等。 体验法 体验法，就是你自己亲自到相关部门去顶岗，做一段时间的业务工作，有了亲身体验自然更容易理解这个岗位的工作。这种方法，最大的优点就是理解业务比较深刻。一旦你几乎成了某岗位的一员后，想想，还有什么比自己帮自己做软件更能够把握需求呢？要给超市收银员写个软件，先到超市卖几天东西，要给仓库做软件，先到仓库发两天货，你的软件偏离用户需求的可能性会大幅度降低。 问卷调查法 问卷调查法，通过编写调查问卷收集需求。通过调查问卷进行需求收集是个效率非常高的方法。对于调研者，不必跑到工作现场，不必跟一个又一个用户一遍又一遍地沟通，只要编写调查问卷、分析回答的内容就可以获得大量的有用信息；对于被调研者，不需要打断自己的工作，可以合理安排回答的时间，还可以更仔细地思考。越是大规模的调研，越能体验这种方法的优越性。 访谈法 访谈法，通过交谈的方式获取需求。需求调研最常见的入手方式是访谈，用得最多的也是访谈。你看电视里经常有谈话节目，两个人或一堆人在一起穷聊，这里所说的访谈跟这种节目有些类似，当然形式、内容比电视中的访谈要丰富得多。访谈可以非常正式，提前约好访谈对象、访谈时间、访谈地点，准备好访谈话题、访谈提纲等；也可以非常随意，电梯上，餐桌上，车上，都可以进行一次偶遇访谈。访谈也未必都需要面对面，通过电话、QQ、邮件、视频聊天等方式进行的沟通咨询，都可以归入访谈的范畴。 单据分析法 单据分析法，分析用户当前使用的纸质或电子单据，通过研究这些单据所承载的信息，分析其产生、流动的方式，从而熟悉业务，挖掘需求。一个组织，在没有信息化管理系统时，它的单据体系其实就是它的信息体系，填写单据的过程就是信息录入的过程，单据传递的过程就是信息流转的过程，最终单据进入的档案室就是数据库。因此，通过分析单据来获得关于信息管理的需求可以收到事半功倍之效。单据分析法是获取需求过程中使用得相当普遍的方法，值得仔细研究下。 报表分析法 报表分析法，通过分析用户使用的报表获取需求。报表跟单据是有本质区别的。单据是在业务处理过程中用户填写的纸质文件，往往是一个信息采集、传递的过程，而报表则是根据一定的规则对批量数据进行检索、统计、汇总，是一个信息加工、分析的过程。分析好现在使用的这些报表，可以深入到管理者的管理神经，弄清楚当前公司管理者感兴趣的信息，最终给各级管理者带来真正的价值。报表是一个信息系统的集大成者，提前做好报表分析，可以加深理解管理脉络，理解信息系统的最终需求。 需求调研会法 头脑风暴 需求调研会法，召集相关人员开会了解需求。当需要讨论的问题牵涉到的相关人员较多时，可以组织需求调研会。相对于需求访谈，需求调研会参与的人员较多，需要做的准备也更麻烦，对会谈过程的把握也更困难，我们并不推荐滥用这个方法。如果人员太多，而你又没有足够的主持能力，或者准备得不够充分，对会议的进程把握不力，很容易把事情搞砸，不但得不到你需要的结论，还会把自己弄得威信扫地，真是大大的划不来啊。 转自：https://www.cnblogs.com/KevinXia/p/7554667.html
mysql查看数据库性能常用命令
摘自： http://blog.csdn.net/iquicksandi/article/details/7970706 http://www.cnblogs.com/w2154/p/4691015.html 网上有很多的文章教怎么配置MySQL服务器，但考虑到服务器硬件配置的不同，具体应用的差别，那些文章的做法只能作为初步设置参考，我们需要根据自己的情况进行配置优化，好的做法是MySQL服务器稳定运行了一段时间后运行，根据服务器的”状态”进行优化。 mysql> show global status; # 可以列出MySQL服务器运行各种状态值，另外，查询MySQL服务器配置信息语句： mysql> show variables; ``` #### 一、慢查询 ```shell mysql> show variables like '%slow%'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | log_slow_queries | ON | | slow_launch_time | 2 | +------------------+-------+ mysql> show global status like '%slow%'; +---------------------+-------+ | Variable_name | Value | +---------------------+-------+ | Slow_launch_threads | 0 | | Slow_queries | 4148 | +---------------------+-------+ 配置中打开了记录慢查询，执行时间超过2秒的即为慢查询，系统显示有4148个慢查询，你可以分析慢查询日志，找出有问题的SQL语句，慢查询时间不宜设置过长，否则意义不大，最好在5秒以内，如果你需要微秒级别的慢查询，可以考虑给MySQL打补丁： http://www.percona.com/docs/wiki/release:start，记得找对应的版本。 打开慢查询日志可能会对系统性能有一点点影响，如果你的MySQL是主-从结构，可以考虑打开其中一台从服务器的慢查询日志，这样既可以监控慢查询，对系统性能影响又小。 二、连接数 经常会遇见”MySQL: ERROR 1040: Too many connections”的情况，一种是访问量确实很高，MySQL服务器抗不住，这个时候就要考虑增加从服务器分散读压力，另外一种情况是MySQL配置文件中max_connections值过小： mysql> show variables like 'max_connections'; +-----------------+-------+ | Variable_name | Value | +-----------------+-------+ | max_connections | 256 | +-----------------+-------+ 这台MySQL服务器最大连接数是256，然后查询一下服务器响应的最大连接数： mysql> show global status like ‘Max_used_connections’; MySQL服务器过去的最大连接数是245，没有达到服务器连接数上限256，应该没有出现1040错误，比较理想的设置是：...
MySQL占用磁盘I/O问题排查
前言：最近查一个磁盘I/O高的问题，涉及到了innodb_flush_log_at_trx_commit 和 sync_binlog 是 MySQL 的两个配置参数，前者是 InnoDB 引擎特有的。之所以把这两个参数放在一起讨论，是因为在实际应用中，它们的配置对于 MySQL 的性能有很大影响。 innodb_flush_log_at_trx_commit 简而言之，innodb_flush_log_at_trx_commit 参数指定了 InnoDB 在事务提交后的日志写入频率。这么说其实并不严谨，且看其不同取值的意义和表现。 当 innodb_flush_log_at_trx_commit 取值为 0 的时候，log buffer 会 每秒写入到日志文件并刷写（flush）到磁盘。但每次事务提交不会有任何影响，也就是 log buffer 的刷写操作和事务提交操作没有关系。在这种情况下，MySQL性能最好，但如果 mysqld 进程崩溃，通常会导致最后 1s 的日志丢失。 当取值为 1 时，每次事务提交时，log buffer 会被写入到日志文件并刷写到磁盘。这也是默认值。这是最安全的配置，但由于每次事务都需要进行磁盘I/O，所以也最慢。 当取值为 2 时，每次事务提交会写入日志文件，但并不会立即刷写到磁盘，日志文件会每秒刷写一次到磁盘。这时如果 mysqld 进程崩溃，由于日志已经写入到系统缓存，所以并不会丢失数据；在操作系统崩溃的情况下，通常会导致最后 1s 的日志丢失。 上面说到的「最后 1s」并不是绝对的，有的时候会丢失更多数据。有时候由于调度的问题，每秒刷写（once-per-second flushing）并不能保证 100% 执行。对于一些数据一致性和完整性要求不高的应用，配置为 2 就足够了；如果为了最高性能，可以设置为 0。有些应用，如支付服务，对一致性和完整性要求很高，所以即使最慢，也最好设置为 1. sync_binlog sync_binlog 是 MySQL 的二进制日志（binary log）同步到磁盘的频率。MySQL server 在 binary log 每写入 sync_binlog 次后，刷写到磁盘。 如果 autocommit 开启，每个语句都写一次 binary log，否则每次事务写一次。默认值是 0，不主动同步，而依赖操作系统本身不定期把文件内容 flush 到磁盘。设为 1 最安全，在每个语句或事务后同步一次 binary log，即使在崩溃时也最多丢失一个语句或事务的日志，但因此也最慢。 大多数情况下，对数据的一致性并没有很严格的要求，所以并不会把 sync_binlog 配置成 1. 为了追求高并发，提升性能，可以设置为 100 或直接用 0. 而和 innodb_flush_log_at_trx_commit 一样，对于支付服务这样的应用，还是比较推荐 sync_binlog = 1. 查看配置参数 使用iostat -dxm 1命令和iotop命令查看磁盘的占用情况，配置修改后： mysql> show variables like '%sync_bin%'; +---------------+-------+...
Markdown语法命令大全（持续整理中……）
0x00 外链教程 点击查看教程 0x01 思维导图画法 0x02 流程图画法 代码： graph TB id((开始)) id-->id4(带文本的圆角矩形) id4 --> id3>带文本的不对称的矩形> id3 --> id1{带文本的菱形} id1 --> id2((结束)) 效果如下： 节点之间的连接 A --> B A带箭头指向B A --- B A不带箭头指向B A -.- B A用虚线指向B A -.-> B A用带箭头的虚线指向B A ==> B A用加粗的箭头指向B A -- 描述 --- B A不带箭头指向B并在中间加上文字描述 A -- 描述 --> B A带箭头指向B并在中间加上文字描述 A -. 描述 .-> B A用带箭头的虚线指向B并在中间加上文字描述 A == 描述 ==> B A用加粗的箭头指向B并在中间加上文字描述 示例 mermaid graph LR A --> B A1 --- B1 A4 -.- B4 A5 -.-> B5 A7 ==> B7 A2 -- 描述 --- B2 A3 -- 描述 --> B3 A6 -. 描述 .->...
Mysql 参数优化
一、Mysql 源码编译参数 shell > yum -y install gcc gcc-c++ make cmake ncurses-devel zlib-devel bison shell > cmake -DCMAKE_INSTALL_PREFIX=/usr/local/mysql \ -DMYSQL_DATADIR=/usr/local/mysql/data \ -DTMPDIR=/usr/local/mysql/data \ -DMYSQL_UNIX_ADDR=/usr/local/mysql/data/mysql.sock \ -DSYSCONFDIR=/etc/my.cnf \ -DWITH_MYISAM_STORAGE_ENGINE=1 \ -DWITH_INNOBASE_STORAGE_ENGINE=1 \ -DWITH_FEDERATED_STORAGE_ENGINE=1 \ -DDEFAULT_CHARSET=utf8 \ -DEXTRA_CHARSETS=all \ -DDEFAULT_COLLATION=utf8_general_ci ## -DCMAKE_INSTALL_PREFIX=/usr/local/mysql 指定 Mysql 安装路径 ## -DMYSQL_DATADIR=/usr/local/mysql/data 指定 Mysql 数据目录 ## -DTMPDIR=/usr/local/mysql/data 指定 Mysql 临时目录 ## -DMYSQL_UNIX_ADDR 指定 Mysql socket ## -DSYSCONFDIR=/etc/my.cnf 指定 Mysql 配置文件 ## -DWITH_MYISAM_STORAGE_ENGINE=1 安装 MyISAM 存储引擎 ## -DWITH_INNOBASE_STORAGE_ENGINE=1 安装 Innodb 存储引擎 ## -DWITH_FEDERATED_STORAGE_ENGINE=1 安装 Federated 存储引擎 ## -DDEFAULT_CHARSET=utf8 指定默认字符集为 utf8 ## -DEXTRA_CHARSETS=all 安装扩展字符集 ## -DDEFAULT_COLLATION=utf8_general_ci 默认排序规则 utf8_general_ci Cmake 参数：http://dev.mysql.com/doc/refman/5.6/en/source-configuration-options.html --------------------------------------------------------------------------------------------- 二、my.cnf 配置文件 ## global_buffers 在内存中缓存从数据文件中检索出来的数据块，可以大大提高查询和更新数据的性能 ## 计算公式：Innodb_buffer_pool_size +...