几年前的一台旧笔记本电脑的虚拟系统运行环境，作为本次练习的运行工具，仅供参考。
[En]
The virtual system running environment of an old notebook computer a few years ago, as the running tool of this practice, is for reference only.
案例环境：Linux、Docker、MySQLCommunity8.0.31、InnoDB。
过早的MySQL版本不一定适用本章内容，仅围绕 InnoDB 引擎的阐述。
一、索引
1.1 索引的管理
-- create 方式创建
create [unique] index {index_name} on {tab_name}({col_name}[(length)]);
-- alter表 方式创建
alter {tab_name} add [unique] index {index_name} on ({col_name}[(length)]);
-- 创建组合索引
create index {index_name} on ({col_name1}[(length)], {col_name2}[(length)], {col_name3}[(length)]);
-- unique：唯一索引
-- col_name：一列为单列索引；逗号隔开的多列为组合索引
-- length：字段中前几个字符有效，避免无限长度（通常能够明显区分值即可的长度；如：员工表的Email，@后面都一样）
-- 查看表中的索引
show index from {tab_name};
-- 删除索引
drop index {index_name} on {tab_name};
1.2 索引创建的场景
过多查询的表，过少写入的表。
数据量过大导致的查询效率慢。
经常作为条件查询的列。
批量的重复值，不适合创建索引；比如
值过少重复的列，适合创建索引；比如
1.3 理想的索引特征
- 尽量能够覆盖常用字段
- 字段值区分度高
- 较小的字段长度(适当的长度，不能越小越好，至少要足够区分每个值)
[En]
small field length (appropriate length, not as small as possible, at least enough to distinguish each value)*
- 相对低频的写入操作，以及高频的查询操作的表和字段上建立索引
通过非聚集索引检索记录的时候，需要2次操作，先在非聚集索引中检索出主键，然后再到聚集索引中检索出主键对应的记录，这个过程叫做回表，比聚集索引多了一次操作。
1.4 非主键索引
where全部为 and时，无所谓位置，都会命中索引（当多个条件中有索引的时候，并且关系是and的时候，会自动匹配索引区分度高的）
where后面为 or 时，索引列 依影响数据范围越精确 按序靠前写。
1.5 索引的使用
使用原则：
- 按条件后面涉及到的列，创建出组合索引
- 越精确的条件，就排在条件的顺序首位，最左匹配原则
-- 按现有数据，计算哪个列最精确；越精确的列，位置越靠前优先。
select sum(depno=28), sum(username like 'Sol%'), sum(position='dev') from tab_emp;
+---------------+---------------------------+---------------------+
| sum(depno=28) | sum(username like 'Sol%') | sum(position='dev') |
+---------------+---------------------------+---------------------+
| 366551 | 3 | 109 |
+---------------+---------------------------+---------------------+
-- 由此得出：username列的范围最精确，应该放到where后的首位；不在组合索引的列放到最后。
-- 如下组合索引的创建方式：
create index {index_name} on {tab_name}(username,position,depno);
-- 如下组合索引的查询方式：
select username,position,depno from tab_emp where username like 'Sol%' and position='dev' and depno=106 and age<27< code></27<>
1.5.1 使用索引查询
这里准备两张两千万相同表数据，测试效果如下图：
1.5.2 组合索引的使用
表创建的组合索引，如下图：
两千万数据表，组合索引查询效果，如下图：
总结：组合索引所包含的列，尽量在 where, order中写全，非索引列或过少的组合索引列可能不会产生索引效果。
1.5.3 高性能分页查询
通常MySQL分页时用到的limit，当limit值过大时，查询效果会很慢。
当如 limit 9000000,10 时，需要先查询出900万数据，再抛掉900万数据；这900万的过程可否省略？
IF：每次查询页面时，记录当前页面上最后一条数据的重要字段，并确定是哪一页；查询下一页时，将其最后一条数据的重要字段作为附加查询条件。
[En]
If: every time you query a page, record the important field of the last piece of data on the current page and identify which page it is; when querying its next page, take the important field of its last piece of data as an additional query condition.
下图示例：usercode 为主要的索引及排序字段，上页的最后一条作为追加条件，再往下取5条，效果有了显著提升。(排序列重复数据呢?) 当然适用于类似code、time等这样重复数据较少的列。
1.6 索引覆盖，避免回表查询
当查询的列包含非索引列时，系统将扫描数据两次。如果只扫描一次数据，也提高了查询效率。
[En]
When the column of the query contains non-index columns, the system scans the data twice. If it can scan the data only once, it also improves the query efficiency.
回表查询的过程：
- 先按已有索引查询到数据，得出此数据的主键值
- 再按主键值，再次检索出具体的数据，获取其它列的值
查询涉及到的列都为组合索引列时，包括： select、 where、 order、 group等，索引覆盖(索引下推)，避免回表查询。
避免使用 *，以避免回表查询；不常用的查询列或 text类型的列，尽量以单独的扩展表存放。
通常列表数据需要的列并不多，查询的时候可以考虑为索引列；通常详细信息时涵盖的列多，可通过主键单独查询。
1.7 命中索引
1.7.1 无效索引
列类型转换可能会导致索引无效；如：
- 字符转数值，会导致索引无效
- 数值转字符，不影响索引。
不建议类型的转换，尽量按原类型查询。
条件中的函数导致索引无效；索引列不能用在函数内。如： where abs(Id) > 200
条件中的表达式导致索引无效；如： where (Id + 1) > 200
避免单列索引和组合索引的重复列；从组合索引的列中删除单列索引。
[En]
Avoid duplicate columns of single-column indexes and combined indexes; remove single-column indexes from columns in combined indexes.
全模糊查询导致索引无效；匹配开头不会影响索引，如 'Sol%'；全模糊或 '%Sol'时无效。
1.7.2 Explain
显示执行过程，查看是否命中索引
explain select * from tab_emp where uname='Sol'
-- 可能用到的索引、实际用到的索引、扫描了的行数
+----+-------------+---------+-------+---------------+---------------+---------+-------+------+-----------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------+-------+---------------+---------------+---------+-------+------+-----------------------+
| 1 | SIMPLE | tab_emp | range | idx_emp_uname | idx_emp_uname | 4 | const | 1 | Using index condition |
+----+-------------+---------+-------+---------------+---------------+---------+-------+------+-----------------------+
在通常情况下，能不能命中索引，取决于索引列的值重复程度；如果是极少重复的值，就很容易命中索引。如果类似于状态或类型的值，重复程度很高，就很难命中索引，这是MySQL自动取舍的结果。
比如：没有索引的列-电话号码，有索引的列-部门，那么很难命中部门索引，因为MySQL认为[电话号码]更精确；或者使用force强行命中，通常MySQL的自动取舍是最有效的。
1.8 查询总结
避免使用 *，以避免回表查询。
不常用的查询列或 text类型的列，尽量以单独的扩展表存放。
条件避免使用函数。
条件避免过多的 or，建议使用 in()/union代替， in中的数据不可以极端海量，至少个数小于1000比较稳妥。
避免子查询，子查询的结果集是临时表不支持索引、或结果集过大、或重复扫描子表；以 join代替子查询，尽量以 inner join代替最为妥当。
避免使用 '%Sol%'查询，或以 'Sol%'代替。
二、表分区
表分区是将物理表的数据文件分成几个数据文件，使得单个数据文件的数量有限，有助于避免扫描整个表的数据，提高查询性能。
[En]
Table partitioning is to divide the data file of a physical table into several data files, which makes the amount of a single data file limited, which helps to avoid scanning the data of the whole table and improve the query performance.
那么，跨区域查询对性能的影响有多大呢？总的来说，表分区带来了很大的性能提升。
[En]
So, how much is the performance impact of cross-region queries? on the whole, table partitioning has brought a lot of performance improvement.
如果表中有主键列，分区列必须是主键列之一。比如：又有自增主键，又想按年份分区，那主键就是组合索引咯。(id+date)
2.1 分区的种类
HASH：按算法，平均分配到各分区
-- 表创建 HASH 分区12个
CREATE TABLE clients (
id INT,
fname VARCHAR(30),
lname VARCHAR(30),
signed DATE
)
PARTITION BY HASH(MONTH(signed))
PARTITIONS 12;
KEY：按算法，无序不等的分配到各分区
-- 表创建12个 KEY 分区
CREATE TABLE clients_lk (
id INT,
fname VARCHAR(30),
lname VARCHAR(30),
signed DATE
)
PARTITION BY LINEAR KEY(signed)
PARTITIONS 12;
RANGE：按划定的范围将数据存放到符合的分区
-- 按年份创建范围分区
CREATE TABLE tr (
id INT,
name VARCHAR(50),
purchased DATE
)
PARTITION BY RANGE(YEAR(purchased)) (
PARTITION p0 VALUES LESS THAN (1990),
PARTITION p1 VALUES LESS THAN (1995),
PARTITION p2 VALUES LESS THAN (2000)
);
LIST：按定义的一组包含值将数据存放到符合的分区
-- LIST 分组包含方式
CREATE TABLE tt (
id INT,
data INT
)
PARTITION BY LIST(data) (
PARTITION p0 VALUES IN (5, 10, 15),
PARTITION p1 VALUES IN (6, 12, 18)
);
2.2 分区的管理
新增 HASH/KEY 分区
-- 将原来的 12 个分区合并为 8 个分区
ALTER TABLE clients COALESCE PARTITION 4;
-- 在原有的基础上增加 6 个分区
ALTER TABLE clients ADD PARTITION PARTITIONS 6;
新增 RANGE/LIST 分区
-- RANGE 追加分区
ALTER TABLE tr ADD PARTITION (PARTITION p3 VALUES LESS THAN (2010));
-- LIST 追加新分区（不可包含已存在的值）
ALTER TABLE tt ADD PARTITION (PARTITION p2 VALUES IN (7, 14, 21));
变更 RANGE/LIST 分区
-- RANGE 拆分原有分区（重组分区）
ALTER TABLE tr REORGANIZE PARTITION p0 INTO (
PARTITION n0 VALUES LESS THAN (1980),
PARTITION n1 VALUES LESS THAN (1990)
);
-- RANGE 合并相邻分区
ALTER TABLE tt REORGANIZE PARTITION s1,s2 INTO (
PARTITION s0 VALUES LESS THAN (1980)
);
-- LIST 重组原有分区
ALTER TABLE tt REORGANIZE PARTITION p1,np INTO (
PARTITION p1 VALUES IN (6, 18),
PARTITION np VALUES in (4, 8, 12)
);
删除指定分区
-- 丢掉指定分区及其数据
ALTER TABLE {TABLE_NAME} DROP PARTITION p2,p3;
-- 删除指定分区，保留数据
ALTER TABLE {TABLE_NAME} TRUNCATE PARTITION p2;
-- 删除表全部分区，保留数据
ALTER TABLE {TABLE_NAME} REMOVE PARTITIONING;
分区详细信息
-- 查询指定分区的数据
SELECT * FROM tr PARTITION (p2);
-- 查询各分区详细
SELECT * FROM information_schema.PARTITIONS WHERE TABLE_SCHEMA=SCHEMA() AND TABLE_NAME='tt';
-- 查看某个分区的状态
ALTER TABLE tr ANALYZE PARTITION p3;
修复分区
-- 检查分区是否损坏
ALTER TABLE tr CHECK PARTITION p1;
-- 修复分区
ALTER TABLE tr REPAIR PARTITION p1, p2;
-- 优化分区，整理分区碎片
ALTER TABLE tr OPTIMIZE PARTITION p0, p1;
-- 当前分区数据，重建分区
ALTER TABLE tr REBUILD PARTITION p0, p1;
三、查询综合测试
2000万相同数据、相同表结构，相同的查询方式，测试效果如下图：(仅供参考)
数据量大了，查询慢；加索引了，数据量越大，写入越慢；
还是物理分表好呀~
四、SQL服务参数优化
仅列出了点官方认可的稳定性良好的可靠的参数，以 InnoDB 为主。
4.1 Connections
[mysqld]
# 保持在缓存中的可用连接线程
# default = -1（无）
thread_cache_size = 16
# 最大的连接线程数(关系型数据库)
# default = 151
max_connections = 1000
# 最大的连接线程数(文档型/KV型)
# default = 100
#mysqlx_max_connections = 700
4.2 缓冲区 Buffer
[mysqld]
# 缓冲区单位大小；default = 128M
innodb_buffer_pool_size = 128M
# 缓冲区总大小，内存的70%，单位大小的倍数
# default = 128M
innodb_buffer_pool_size = 6G
# 以上两个参数的设定，MySQL会自动改变 innodb_buffer_pool_instances 的值
4.3 Sort merge passes
[mysqld]
# 优化 order/group/distinct/join 的性能
# SHOW GLOBAL STATUS 中的 Sort_merge_passes 过多就增加设置
# default = 1K
max_sort_length = 8K
# default = 256K
sort_buffer_size = 2M
# 通常别太大，海量join时大
# default = 256K
#join_buffer_size = 128M
4.4 I/O 线程数
[mysqld]
# 异步I/O子系统
# default = NO
innodb_use_native_aio = NO
# 读数据线程数
# default = 4
innodb_read_io_threads = 32
# 写入数据线程数
# default = 4
innodb_write_io_threads = 32
4.5 Capacity 容量
[mysqld]
# default = 200
innodb_io_capacity = 1000
# default = 2000
innodb_io_capacity_max = 2500
# 数据日志容量值越大，恢复数据越慢
# default = 100M
innodb_redo_log_capacity = 1G
# 数据刷新到磁盘的方式
# 有些同学说用 O_DSYNC 方式，在写入时，有很大提升。但官网说：
# InnoDB does not use O_DSYNC directly because there have been problems with it on many varieties of Unix.
# 也就是少部分系统可以使用，或者已经过确认。
# 个人认为，默认值最可靠
# innodb_flush_method = fsync
4.6 Open cache
[mysqld]
# default = 5000
open_files_limit = 10000
# 计算公式：MAX((open_files_limit-10-max_connections)/2,400)
# default = 4000
table_open_cache = 4495
# 超过16核的硬件，肯定要增加，以发挥出性能
# default = 16
table_open_cache_instances = 32
五、写入综合测试
测试目的：
经过【四、SQL服务参数优化】的配置后，分别测试空表状态批量写入200万和500万数据的耗时。
测试场景：
一台几年前的破笔记本，创建的虚拟机4C8G，Docker + MySQL8.0.31。
桌面应用以36个线程写入随机数据。
批量写入脚本： INSERT INTO TABLE ... VALUES (...),(...),(...) 的方式， INSERT 每次1000条。
表结构：聚集索引 + 两列的非聚集索引 + 一组三列的组合索引；(参照 1.5.2)
+------------+--------------+------+-----+-------------------+-------------------+
| Field | Type | Null | Key | Default | Extra |
+------------+--------------+------+-----+-------------------+-------------------+
| id | bigint | NO | PRI | NULL | auto_increment |
| usercode | varchar(32) | YES | MUL | NULL | |
| title | varchar(128) | YES | | NULL | |
| age | int | YES | MUL | NULL | |
| gender | char(1) | YES | | 男 | |
| phone | char(11) | YES | | NULL | |
| job | varchar(32) | YES | | NULL | |
| department | varchar(32) | YES | | NULL | |
| createtime | datetime | NO | PRI | CURRENT_TIMESTAMP | DEFAULT_GENERATED |
+------------+--------------+------+-----+-------------------+-------------------+
测试结果：
逐步追加MySQL服务参数配置+表分区，最终有了成倍的性能提升；每次测试后的日志记录了优化的递进过程；
如下图：(日志不够细，懂就行)
经过逐步优化：
200万数据写入耗时从 9分4秒，提升到 5分50秒；(无表分区)
500万数据写入耗时从 41分33秒，提升到 6分50秒。(有表分区)
Original: https://www.cnblogs.com/Sol-wang/p/17076128.html
Author: Sol-wang
Title: MySQL8.0性能优化（实践）
相关阅读
Title: 从问题域和解决域看需求评审
01、 什么是需求评审？
需求是用户在产品使用过程中，发现产品存在无法满足的业务场景或无法解决的业务问题，进而提出的诉求。
[En]
Demand is the demand that users put forward when they find that there are unsatisfiable business scenarios or unsolvable business problems in the process of using the product.
需求评审可以区分为两个维度，一个是评审需求的问题域，即该需求要解决的问题是否真实存在；另一个是评审需求的解决方案域，即解决问题的方案是否合理合适。
[En]
Requirements review can be divided into two dimensions, one is to review the problem domain of the requirements, that is, whether the problem to be solved by the requirements is real, and the other is to review the solution domain of the requirements, that is, whether the solution to the problem is reasonable and appropriate.
02、 为什么要做需求评审？
需求是连接用户和产品的重要桥梁，是业务价值的载体，持续的需求提出与交付是产品生命力的一种表现。通过评审需求的问题域，识别需求的产生原因与业务价值，确保做正确的事；通过评审需求的解决方案域，确保各方是正确地做事。
[En]
Demand is an important bridge to connect users and products, and the carrier of business value. Continuous demand and delivery is a manifestation of product vitality. By reviewing the problem domain of the requirements, identify the cause and business value of the requirements, and ensure that the right thing is done; by reviewing the solution domain of the requirements, ensure that all parties are doing things correctly.
03、 需求评审怎么做？
需求的问题域评审
提问题比解决问题更重要，提问题相当于指出方向。问题的存在比问题的内容和形式更本质。相比较于提出问题，人们更擅长于给出答案。我们发现，很多需求的描述是”我要XXXX”，需求提出人往往给出的是答案，而不是问题。在评审需求的问题域时，需要警惕，避免陷入答案的讨论，只有发现核心问题、找出问题本质，才能判断答案是否正确。
有些公司会有专门的需求审批流程，例如业务人员提出需求、部门经理审核，通过后传递到研发团队，研发团队进行系统实现。这种场景下，需求问题域的评审是放在了业务部门、研发团队只是落地执行，本文所描述的需求问题域评审，指的是利益相关方和研发团队共同评审。
[En]
Some companies will have a special requirements approval process, such as business personnel put forward requirements, department managers review, passed to the R & D team, R & D team for system implementation. In this scenario, the review of the requirement problem domain is placed in the business department, and the R & D team is only implemented on the ground. the requirement problem domain review described in this paper refers to the joint review of stakeholders and R & D team.
需求的问题域评审，常见的组织者是产品经理或需求分析师，参与人有需求提出人、利益相关方，通常以会议形式进行。为了提高需求评审的效率与质量，以下方式建议：
[En]
In the problem domain review of requirements, the common organizer is the product manager or requirements analyst, and the participants have demand proposers and stakeholders, usually in the form of meetings. In order to improve the efficiency and quality of requirements review, the following ways are recommended:
会前准备
用户的需求往往只是一句话，并且通常表达的是要什么而不是为什么。如果所有的需求澄清都在会议中进行，那么势必会导致会议的冗长和低效。因此，产品经理或需求分析师，需要在会议前进行一定的调研与分析，了解一句话需求背后的业务问题、核心诉求。常用的调研分析方法或工具，包括，5W1H、流程图、用户旅程地图、事件风暴等等。而这些方法的核心都是，从用户角度出发、围绕业务场景，只谈业务、不谈解决方案。
识别相关方：只有找对了人，才能事半功倍。基于需求调研，可以判断和邀请合适的利益相关方参与到评审会议中。
识别关键问题：基于调研信息，识别出已知的共识、影响决策与判断的关键问题。
提前通知与明确目标：可以整理一些文档或资料，让相关方在会前了解背景、要讨论的问题及要达成的目标。
会议中
明确会议目标：需求评审的目标是判断需求的合理性、排定需求优先级，聚焦的是需求问题域，各利益相关方在该会议上，探讨该需求所呈现的问题是否存在、是否是伪需求、对业务的影响和紧急度是怎么样的。而对于需求解决方案域，在这个会议中，聚焦的是问题解决后能带来什么，例如是工作效率的提升、业务操作错误率的降低，避免陷入解决方案的细节讨论中。
控制会议节奏：会议组织者可以通过约定会议时长、引导参会人员聚焦目标、及时对不相关问题讨论喊停等方式，把控会议节奏，始终围绕目标和具体问题进行讨论。
做好会议记录：对会议中的共识结论、待定问题，做好记录。
会议后
跟进待定问题，及时清理待定问题，避免问题遗留时间过长而不了了之。
[En]
Follow up the pending problems, clean up the undetermined problems in time, and avoid leaving the problems for too long.
需求的解决域评审
在充分理解和认识了需求后，提供的解决方案是否能高效合理地解决问题，最终交付的产品是否能实现业务价值，是需求解决域评审要回答的问题。
[En]
After fully understanding and understanding of the requirements, whether the solution provided can solve the problem efficiently and reasonably, and whether the final delivered products can achieve business value, are the questions to be answered by the requirements solution domain review.
评审需求解决方案时通常要面向两类对象，目的和侧重点有所差异，具体如下：
[En]
The review of requirements solutions is usually oriented to two types of objects, with different purposes and priorities, as follows:
需求的解决方案通常以PRD、产品原型为载体，为了提高评审效率，有以下几点参考：
会议前
可以根据评审侧重点发出对应资料，相关人员提前阅读和查看，并标记出重难点问题；同时，需求评审并不是一次会议就一蹴而就的，对于需求的实现重难点，在设计过程中，应该是在小范围进行了讨论和初步共识的。通过需求评审，一方面是传递需求，另一方面也可以借助不同角色的专业背景和知识，对需求设计本身进行查漏补缺。
[En]
The corresponding materials can be sent out according to the focus of the review, and the relevant personnel can read and review them in advance, and mark the important and difficult problems; at the same time, the requirements review is not achieved overnight in a meeting, as for the important and difficult points of the requirements, in the design process, it should be discussed on a small scale and reached a preliminary consensus. Through the requirements review, on the one hand, we can transfer the requirements, on the other hand, we can check and fill the gaps in the requirements design itself with the help of the professional background and knowledge of different roles.
会议中
控制会议节奏，尽量依据事实进行问题讨论，避免假设性的发散和主观判断的纠缠；对结论性的内容以及待定问题，进行归纳总结。
[En]
Control the pace of the meeting, discuss the issues based on the facts as far as possible, avoid hypothetical divergence and the entanglement of subjective judgment; summarize the concluding contents and undetermined issues.
会议后
对待定问题，进行跟踪与反馈，根据实际情况，可以组织需求的二次评审。
[En]
Follow up and feedback on the identified problems, and organize the second review of the requirements according to the actual situation.
为了确保需求从问题理解、方案设计、系统实现是一致的，避免理解偏差带来的返工浪费，除了上述两类需求评审之外，还建议在有条件的情况下进行需求串讲，即开发人员借助技术设计讲解其对需求的理解和设计、测试人员借助测试用例讲解其对需求的理解和测试，相信，经过这样的多轮需求对齐后，呈现给用户的产品一定是可用的。
[En]
In order to ensure that the requirements are consistent from the problem understanding, scheme design and system implementation, and to avoid the rework waste caused by the understanding deviation, in addition to the above two types of requirements review, it is also suggested that the requirements string should be carried out under conditional conditions. that is, developers explain their understanding and design of requirements with the help of technical design, and testers explain their understanding and testing of requirements with the help of test cases. After such multiple rounds of demand alignment, the product presented to the user must be available.
04、 常用的工具介绍
需求管理是研发过程中的一个持续且重要的工作，合理使用工具能够提高研发管理效率。
[En]
Demand management is a continuous and important work in the process of R & D. rational use of tools can improve the efficiency of R & D management.
猪齿鱼研发管理工具，提供了统一的需求收集渠道，连接用户与研发团队。同时，可以根据公司的管理规范，自定义需求提报后的审批流程，以方便各方及时获取和审核需求信息。需求池让需求回归业务本质、回归问题根本，解决了需求问题域的问题。
[En]
Pig Tooth Fish R & D management tools provide a unified demand collection channel to connect users and R & D team. At the same time, the approval process after demand submission can be customized according to the company’s management standards, so as to facilitate all parties to obtain and review demand information in a timely manner. The demand pool makes the demand return to the nature of the business and the root of the problem, and solves the problem of the demand problem domain.
需求评审通过后，一方面可以快速转换为史诗、故事甚至是缺陷，以设计产品蓝图、规划产品路线，另一方面也可以快速转换为研发团队的工作任务，例如设计任务，以落地产品蓝图的执行。同时，支持以需求视角跟踪和查看从提出、审批、设计、执行、发布的全流程。完整管理需求的解决域，让提问人和答题人信息对称、进度可视、协作顺畅。
[En]
After the requirements review is passed, on the one hand, it can be quickly converted into epics, stories and even defects to design product blueprints and plan product routes, on the other hand, it can also be quickly transformed into tasks of the R & D team, such as design tasks. to implement the landing product blueprint. At the same time, it supports tracking and viewing the whole process of proposal, approval, design, execution and release from a requirements perspective. Fully manage the solution domain of requirements, so that the questioner and respondent have symmetrical information, visual progress and smooth collaboration.
同时，借助需求的评论功能，可以建立需求提出人与研发团队的沟通渠道，对需求澄清过程中的重要信息实现线上记录。
[En]
At the same time, with the help of the requirement comment function, the communication channel between the demand proposer and the R & D team can be established to record the important information in the process of requirements clarification.
需求是研发管理工作中的第一步，在了解了需求评审的问题域和解决域之后，怎样才能合理规划需求排期和研发节奏、为需求的落地保驾护航，我们将在下一期与您共同探讨，敬请期待！
[En]
Demand is the first step in R & D management. After understanding the problem domain and solution domain of requirements review, how can we reasonably plan the demand scheduling and R & D rhythm, and escort the landing of the demand? we will discuss with you in the next issue. Please look forward to it!
上海甄知科技有限公司（简称甄知科技）是一家服务管理数字化领先企业，由业界知名的企业数字化综合服务商–上海汉得信息技术股份有限公司（股票代码：300170）孵化而成，承袭汉得信息20年的企业信息化服务经验和对企业数智化建设的深入理解，以产品燕千云、猪齿鱼，为用户提供智能化IT运维、人性化员工服务、全方位客户成功、可视化软件研发的SaaS管理平台+PaaS定制能力，强势助力各行业企业数智化转型升级。
甄知科技陪伴众多优秀企业共同成长
Original: https://www.cnblogs.com/choerodon/p/16384539.html
Author: 猪齿鱼开发管理平台
Title: 从问题域和解决域看需求评审
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/363480/
转载文章受原作者版权保护。转载请注明原作者出处！
