trxcreator

1. AMD新出的线程撕裂者哪家主板最适合最近在关注这个u

华硕、微星、技嘉等几大一线厂商，都推出了适配Zen2架构线程撕裂者的主板，请关注各大IT网站的推荐测评文章。

2. MYSQL的事务隔离级别，MVCC，readView和版本链小结

MVCC(Mutil-Version Concurrency Control)，就是多版本并发控制。这种并发控制的方法，主要应用在RC和RR隔离级别的事务当中，利用执行select操作时，访问记录版本链，使得不同事物的读写，写读可以并发执行，提高系统性能。

Innodb 有两个隐藏字段 trx_id(事务id)和roll_pointer(回滚指针)。
transaction id ：
innoDB里面每个事务有一个唯一的事务ID，叫作transaction id，它是在事务开始的时候向InnoDB的事务系统申请的，是按申请顺序严格递增的。
roll_pointer ：
指向上一事务版本的指针。
版本链 ：
是一个单链表结构，对于同一行数据，每一个事务对其进行更新的时候都会产生一个新的版本，就会存储在这个链表当中。

一个存储事务id的列表。

readview的几个参数：
m_ids:表示活跃事务id列表
min_trx_id:活跃事务中的最小事务id
max_trx_id:已创建的最大事务id
creator_trx_id:当前的事务id。
readview的生成时机：
RC隔离级别：每次读取数据前，都生成一个readview；
RR隔离级别：在第一次读取数据前，生成一个readview；

使用场景：
[ 创建事务节点 ] 当我创建一个新的事务需要读尘春握取森者一行数据, 我会查询活跃的事务列表; 假设我当前的事务id是200, 当前活跃的事务id没有我的200, 因此需要去拷贝一个最新的不活跃事务并在版本链最后插入一个新节点200; mysql会去对比版本链和readView, 假设版本链数据为[1,50,100,150], 活跃列表为[100,150], 说明100和150都是未提交的活跃事务, 再向前一个节点50不在活跃事务列表说明事务50已经提交, 所以事务200拷贝事务50并插入版本链最后, 且将200追加到readView活跃列表的最后一个元素

[ 使用事务节点 ] 当我再次进行200号事务的查询或修改, 我需要读版本链的数据, 因为上一次操作已经在版本链做了200号节点, 因此我读的数据都是200号节点的数据, 这样就隔离了其他未提交的事务; 我的全部增删派庆查改都在200号版本链上进行

[ readView实现事务隔离级别 ]以上两点都是基于隔离级别"读已提交"来进行说明的; 当mysql设置为"可重复读"时, 不同事务仍然是保存在版本链的不同节点上, 只不过新的事务创建的时候拷贝了当下的readView列表, 只要新事物不提交就一直使用这个拷贝的活跃列表; 假设此时100号数据提交了, 我在新事务执行了select 会去查活跃列表发现100号事务还是未提交状态, 因此读取到的还是50号事务提交的记录。

原子性，一致性，隔离性，持久性。

未提交读（read uncommitted）、提交读（read committed）、可重复读（repeatable read）、序列化读（serializable）

3. 华硕rog strix x570-e gaming主板能装3990x CPU吗

华硕rog strix x570-e gaming主板不能装3990x CPU。
锐龙 Threadripper 3990X采用的是Socket sTRX4接口，必须搭配专用的TRX40芯片组主板。X570主板只能使用AM4接口的处理器，最高Ryzen 9 3950X。
如果想要购买更高配置的电脑，推荐购买外星人M15 R6这款，它采用预言设计2.0，拥有轻薄金属机身，薄至22.85mm，并且搭载着第11代酷睿i7处理器以及RTX3060二代光追显卡。
在散热方面，其采用了升级版的超级散热架构：使用独特的C型CPU均热板，并结合双进气双排气设计，载有超压驱动风扇。“三强联合”，散热性能十分强大。
此外，这款游戏本还支持QHD 240Hz高刷电竞屏，并载有独特的AWCC智动能技术平台，其游戏定制光效高达1680万色，并支持190+款游戏灯效联动，游戏效果十分高清，游戏体验十分爽！

4. Mysql隔离级别之MVCC的ReadView的理解

比较常用的两种分别是读已提交、可重复读，那么Mysql是如何保证多个事务读取一条数据的隔离性的？

当我们读取一条被其他事务变更的数据时,会在undo Log中产生一条变更前的日志.这个日志可以专门用于回滚。

我们大概来看一下这个日志的大概结构:

前面三个字段属于变更前的，另外：
trx_id : 代表是哪个事务编号修改的。

roll_pointer : 相当于一个链表，往下查找就是上一次更改前的。当一条数据被更改了多次之后，由该字段构建成一个链表俗称 版本链 。

有了undo Log的话可以很快追溯到更改之前的数据，有了这个之后，假设多个事务都在读同一条记录，并且还发生了修改，这个时候

多版本并发控制，指的就是在使用读提交和可重复读隔离级别的事务，在执行普通select操作时，访问记录版本链的过程；使不同事务的读写、写读操作并发执行，提高系统性能；

基于当前活跃事务列表构成的ReadView，当某个事务创建ReadView时，会将当前活跃的事务也加入其中。

我们来看一下大概结构：

readview 中四个比较重要的概念：
m_ids ：表示在生成携橘readview时，当前系统中 活跃的读写事务id列表 ；

min_trx_id ：表示在生成readview时，当前系统中活跃的读写事务中最小的事务id，也就是m_ids中最小的值；
max_trx_id ：表示生成readview时，系统中应该分配给下一个事务的id值；
creator_trx_id ：表示生成该readview的事务的事务id；

有了readview，在访问某条记录时，按照以下步骤判断记录的某个版本是否可见:

下面是对于同一条数据的多个事务读取流程:

ReadView( 简称RV )一旦创建是不可变的，即便其中某个线程事务提交了，也不会影响当前线程创建的ReadView，你可以理解为一个副本快照。

总的来说判断就三个条件:

基于上述规则，很好的解决了一致性读的问题；当前线程创建完RV之后，读到的数据都是相同的；不会读到其他事务未提交和后提交的数据。

可重复读的RV是以一个事务的开始和结束作为它的生命周期的

读提交级别是能够读到其他事务提交的数据的，那么这个时候上面的流程是不是满足不了呀？因为假设ABC都在一个RV之中，C提交了数据，但是B看不到呀，因为条件2就满足不了呀；

这个时候Mysql就把这个级别的RV做了调整， 每次读取数据的时候会创建一个新的ReadView

当RV中的事务B提交了事务的时候，A每次会创建一个新的RV来查看数据版本，新的RV的m_ids肯定是不包含已经提交的事务B的，这个时候就能够读到事务B的数据了。

之前一直以为可重复读没有解决幻读的问题，现在基于这个流程另外加上命令行调试之后发现应该是解决了的。

因为一旦创建RV的话，当前活跃事务快照已经生成，这个时候如果新来的事务或者快照内的事务新增了数据空和也斗隐盯不会读到：

如有问题，欢迎留言交流。

5. 波场发币教程TRC20发币教程TRX发币教程波场代币智能合约发币教程

波场链的币种叫TRC20代币，部署到TRX的主网上，波场发币教程也很简单，一起学习下吧，波场发币教程TRC20发币教程TRX发币教程波场代币智能合约发币教程，不会的退出阅读模式，我帮你代发

TRC-20

TRC-20是用于TRON区块链上的智能合约的技术标准，用于使用TRON虚拟机（TVM）实施代币。

实现规则

3 个可选项

通证名称

string public constant name = “TRONEuropeRewardCoin”;

通证缩写

string public constant symbol = “TERC”;

通证精度

uint8 public constant decimals = 6;

6 个必选项

contract TRC20 {

function totalSupply() constant returns (uint theTotalSupply);

function balanceOf(address _owner) constant returns (uint balance);

function transfer(address _to, uint _value) returns (bool success);

function transferFrom(address _from, address _to, uint _value) returns (bool success);

function approve(address _spender, uint _value) returns (bool success);

function allowance(address _owner, address _spender) constant returns (uint remaining);

event Transfer(address indexed _from, address indexed _to, uint _value);

event Approval(address indexed _owner, address indexed _spender, uint _value);

}

totalSupply()

这个方法返回通证总的发行量。

balanceOf()

这个方法返回查询账户的通证余额。

transfer()

这个方法用来从智能合约地址里转账通证到指定账户。

approve()

这个方法用来授权第三方（例如DAPP合约）从通证拥有者账户转账通证。

transferFrom()

这个方法可供第三方从通证拥有者账户转账通证。需要配合approve()方法使用。

allowance()

这个方法用来查询可供第三方转账的查询账户的通证余额。

2 个事件函数

当通证被成功转账后，会触发转账事件。

event Transfer(address indexed _from, address indexed _to, uint256 _value)

当approval()方法被成功调用后，会触发Approval事件。

event Approval(address indexed _owner, address indexed _spender, uint256 _value)

合约示例

pragma solidity ^0.4.16;

interface tokenRecipient { function receiveApproval(address _from, uint256 _value, address _token, bytes _extraData) external; }

contract TokenTRC20 {

// Public variables of the token

string public name;

string public symbol;

uint8 public decimals = 18;

// 18 decimals is the strongly suggested default, avoid changing it

uint256 public totalSupply;

// This creates an array with all balances

mapping (address => uint256) public balanceOf;

mapping (address => mapping (address => uint256)) public allowance;

// This generates a public event on the blockchain that will notify clients

event Transfer(address indexed from, address indexed to, uint256 value);

// This notifies clients about the amount burnt

event Burn(address indexed from, uint256 value);

/**

* Constructor function

*

* Initializes contract with initial supply tokens to the creator of the contract

*/

function TokenTRC20(

    uint256 initialSupply,

    string tokenName,

    string tokenSymbol

) public {

    totalSupply = initialSupply * 10 ** uint256(decimals);  // Update total supply with the decimal amount

    balanceOf[msg.sender] = totalSupply;                // Give the creator all initial tokens

    name = tokenName;                                  // Set the name for display purposes

    symbol = tokenSymbol;                              // Set the symbol for display purposes

}

/**

* Internal transfer, only can be called by this contract

*/

function _transfer(address _from, address _to, uint _value) internal {

    // Prevent transfer to 0x0 address. Use burn() instead

    require(_to != 0x0);

    // Check if the sender has enough

    require(balanceOf[_from] >= _value);

    // Check for overflows

    require(balanceOf[_to] + _value >= balanceOf[_to]);

    // Save this for an assertion in the future

    uint previousBalances = balanceOf[_from] + balanceOf[_to];

    // Subtract from the sender

    balanceOf[_from] -= _value;

    // Add the same to the recipient

    balanceOf[_to] += _value;

    emit Transfer(_from, _to, _value);

    // Asserts are used to use static analysis to find bugs in your code. They should never fail

    assert(balanceOf[_from] + balanceOf[_to] == previousBalances);

}

/**

* Transfer tokens

*

* Send `_value` tokens to `_to` from your account

*

* @param _to The address of the recipient

* @param _value the amount to send

*/

function transfer(address _to, uint256 _value) public {

    _transfer(msg.sender, _to, _value);

}

/**

* Transfer tokens from other address

*

* Send `_value` tokens to `_to` on behalf of `_from`

*

* @param _from The address of the sender

* @param _to The address of the recipient

* @param _value the amount to send

*/

function transferFrom(address _from, address _to, uint256 _value) public returns (bool success) {

    require(_value <= allowance[_from][msg.sender]);    // Check allowance

    allowance[_from][msg.sender] -= _value;

    _transfer(_from, _to, _value);

    return true;

}

/**

* Set allowance for other address

*

* Allows `_spender` to spend no more than `_value` tokens on your behalf

*

* @param _spender The address authorized to spend

* @param _value the max amount they can spend

*/

function approve(address _spender, uint256 _value) public

    returns (bool success) {

    allowance[msg.sender][_spender] = _value;

    return true;

}

/**

* Set allowance for other address and notify

*

* Allows `_spender` to spend no more than `_value` tokens on your behalf, and then ping the contract about it

*

* @param _spender The address authorized to spend

* @param _value the max amount they can spend

* @param _extraData some extra information to send to the approved contract

*/

function approveAndCall(address _spender, uint256 _value, bytes _extraData)

    public

    returns (bool success) {

    tokenRecipient spender = tokenRecipient(_spender);

    if (approve(_spender, _value)) {

        spender.receiveApproval(msg.sender, _value, this, _extraData);

        return true;

    }

}

/**

* Destroy tokens

*

* Remove `_value` tokens from the system irreversibly

*

* @param _value the amount of money to burn

*/

function burn(uint256 _value) public returns (bool success) {

    require(balanceOf[msg.sender] >= _value);  // Check if the sender has enough

    balanceOf[msg.sender] -= _value;            // Subtract from the sender

    totalSupply -= _value;                      // Updates totalSupply

    emit Burn(msg.sender, _value);

    return true;

}

/**

* Destroy tokens from other account

*

* Remove `_value` tokens from the system irreversibly on behalf of `_from`.

*

* @param _from the address of the sender

* @param _value the amount of money to burn

*/

function burnFrom(address _from, uint256 _value) public returns (bool success) {

    require(balanceOf[_from] >= _value);                // Check if the targeted balance is enough

    require(_value <= allowance[_from][msg.sender]);    // Check allowance

    balanceOf[_from] -= _value;                        // Subtract from the targeted balance

    allowance[_from][msg.sender] -= _value;            // Subtract from the sender's allowance

    totalSupply -= _value;                              // Update totalSupply

    emit Burn(_from, _value);

    return true;

}

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

60

61

62

63

64

65

66

67

68

69

70

71

72

73

74

75

76

77

78

79

80

81

82

83

84

85

86

87

88

89

90

91

92

93

94

95

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

112

113

114

115

116

117

118

119

120

121

122

123

124

125

126

127

128

129

130

131

132

133

134

135

136

137

138

139

140

}

Next Previous

就是这么简单，你学会了吗？

6. MySQL innodb引擎深入讲解

表空间(ibd文件),一个MySQL实例可以对应多个表空间，用于存储记录，索引等数据。

段，分为数据段、索引段、回滚段，innodb是索引组织表，数据段就是B+Tree的叶子节点，索引段为非叶子节点，段用来管理多个区。

区，表空间的单元结构，每个区的大小为1M,默认情况下，innodb存储引擎页大小为16K，即一个区中一共有64个连续的页。

页，是innodb存储引擎磁盘管理的最小单元，每个页的大小为16K，为了保证页的连续性，innodb存储引擎每次从磁盘申请4~5个区。

行，innodb存储引擎数据是按行进行存储的。Trx_id 最后一次事务操作的id、roll_pointer滚动指针。

i nnodb的内存结构 ，由Buffer Pool、Change Buffer和Log Buffer组成。

Buffer Pool : 缓冲池是主内存中的一个区域，里面可以缓存磁盘上经常操作的真实数据，在执行增删改查操作时，先操作缓冲池中的数据(若缓冲池么有数据，则从磁盘加载并缓存)，然后再以一定频率刷新磁盘，从而减少磁盘IO，加快处理速度。

缓冲池以page页为单位，底层采用链表数据结构管理page，根据状态，将page分为三种类型:

1、free page 即空闲page，未被使用。

2、clean page 被使用page，数据没有被修改过。

3、dirty page 脏页，被使用page，数据被修改过，这个page当中的数据和磁盘当中的数据 不一致。说得简单点就是缓冲池中的数据改了，磁盘中的没改，因为还没刷写到磁盘。

Change Buffer ：更改缓冲区(针对于非唯一二级索引页)，在执行DML语句时，如果这些数据page没有在Buffer Pool中，不会直接操作磁盘，而会将数据变更存在更改缓冲区Change Buffer中，在未来数据被读取时。再将数据合并恢复到Buffer Pool中，再将合并后的数据刷新到磁盘中。

二级索引通常是非唯一的，并且以相对随机的顺序插入二级索引页，同样，删除和更新可能会影响索引树中不相邻的二级索引页。如果每一次都操作磁盘，会造成大量磁盘IO，有了Change Buffer之后，我们可以在缓冲池中进行合并处理，减少磁盘IO。

Adaptive Hash Index： 自适应hash索引，用于优化对Buffer Pool数据的查询，InnoDB存储引擎会监控对表上各索引页的查询，如果观察到hash索引可以提升速度，则建立hash索引，称之为自适应hash索引。无需人工干预，系统根据情况自动完成。

参数：innodb_adaptive_hash_index

Log Buffer: 日志缓冲区，用来保存要写入到磁盘中的log日志数据(redo log、undo log)，默认大小为16M，日志缓冲区的日志会定期刷新到磁盘中，如果需要更新，插入或删除许多行的事务，增加日志缓冲区的大小可以节省磁盘IO。

参数: innodb_log_buffer_size 缓冲区大小

innodb_flush_log_at_trx_commit 日志刷新到磁盘时机

innodb_flush_log_at_trx_commit=1 表示日志在每次事务提交时写入并刷新到磁盘

2 表示日志在每次事务提交后写入，并每秒刷新到磁盘一次

0 表示每秒将日志写入并刷新到磁盘一次。

InnoDB 的磁盘结构，由系统表空间(ibdata1)，独立表空间(*.ibd),通用表空间，撤销表空间(undo tablespaces), 临时表空间(Temporary Tablespaces), 双写缓冲区(Doublewrite Buffer files), 重做日志(Redo Log).

系统表空间(ibdata1)： 系统表空间是更改缓冲区的存储区域，如果表是在系统表空间而不是每个表文件或者通用表空间中创建的，它也可能包含表和索引数据。

参数为: innodb_data_file_path

独立表空间(*.ibd): 每个表的文件表空间包含单个innodb表的数据和索引，并存储在文件系 统上的单个数据文件中。 参数: innodb_file_per_table

通用表空间: 需要通过create tablespace 语法创建，创建表时 可以指定该表空间。

create tablespace xxx add datafile 'file_name' engine=engine_name

create table table_name .... tablespace xxx

撤销表空间(undo tablespaces): MySQL实例在初始化时会自动创建两个默认的undo表空间(初始大小16K，undo_001,undo_002)，用于存储undo log 日志

临时表空间(Temporary Tablespaces)： innodb使用会话临时表空和全局表空间，存储用 户创建的临时表等数据。

双写缓冲区(Doublewrite Buffer files)： innodb引擎将数据页从Buffer Pool刷新到磁盘前，先将数据页写入缓冲区文件中，便于系统异常时恢复数据。

重做日志(Redo Log)： 是用来实现事务的持久性，该日志文件由两部分组成，重做日志缓冲区(redo log buffer)以及重做日志文件(redo log)，前者是在内存中，后者在磁盘中，当事务提交之后会把修改信息都会存储到该日志中，用于在刷新脏页到磁盘时，发送错误时，进行数据恢复使用。以循环方式写入重做日志文件，涉及两个文件ib_logfile0,ib_logfile1。

那内存结构中的数据是如何刷新到磁盘中的? 在MySQL中有4个线程负责刷新日志到磁盘。

1、Master Thread， mysql核心后台线程，负责调度其它线程，还负责将缓冲池中的数据异 步刷新到磁盘中，保持数据的一致性，还包括脏页的刷新，合并插入缓冲、undo页的回 收。

2、IO Thread，在innodb存储引擎中大量使用了AIO来处理IO请求，这样可以极大地提高数 据库的性能，而IO Thead主要负责这些IO请求的回调。

4个读线程 Read thread负责读操作

4个写线程write thread负责写操作

1个Log thread线程 负责将日志缓冲区刷新到磁盘

1个insert buffer线程 负责将写入缓冲区内容刷新到磁盘

3、Purge Thread，主要用于回收事务已经提交了的undo log，在事务提交之后，undo log 可能不用了，就用它来回收。

4、Page Cleaner Thread， 协助Master Thread 刷新脏页到磁盘的线程，它可以减轻主线程 的压力，减少阻塞。

事务就是一组操作的集合，它是一个不可分割的工作单位，事务会把所有的操作作为一个整体一起向系统提交或撤销操作请求，即这些操作要么同时成功，要么同时失效。

事务的4大特性分为:

如何保证事务的4大特性，原子性，一致性和持久性是由innodb存储引擎底层的两份日志来保证的，分别是redo log和undo log。对于隔离性是由锁机制和MVCC(多版本并发控制)来实现的。

redo log，称为重做日志，记录的是事务提交时数据页的物理修改，是用来实现事务的持久性。该日志文件由两部分组成: 重做日志缓冲redo log buffer及重做日志文件redo log file，前者是在内存中，后者是在磁盘中，当事务提交之后会把所有修改信息都存到该日志文件中，用于在刷新脏页到磁盘，发送错误时，进行数据的恢复使用，从而保证事务的持久性。

具体的操作流程是：

1、客户端发起事务操作，包含多条DML语句。首先去innodb中的buffer pool中的数据页去查找有没有我们要更新的这些数据，如果没有则通过后台线程从磁盘中加载到buffer pool对应的数据页中，然后就可以在缓冲池中进行数据操作了。

2、此时缓冲池中的数据页发生了变更，还没刷写到磁盘，这个数据页称为脏页。脏页不是实时刷新到磁盘的，而是根据你配置的刷写策略进行刷写到磁盘的（innodb_flush_log_at_trx_commit，0,1,2三个值）。如果脏页在往磁盘刷新的时候出现了故障，会丢失数据，导致事务的持久性得不到保证。为了避免这种现象，当对缓冲池中的数据进行增删改操作时，会把增删改记录到redo log buffer当中，redo log buffer会把数据页的物理变更持久化到磁盘文件中(ib_logfile0/ib_logfile1)。如果脏页刷新失败，就可以通过这两个日志文件进行恢复。

undo log，它是用来解决事务的原子性的，也称为回滚日志。用于记录数据被修改前的信息，作用包括:提供回滚和MVCC多版本并发控制。

undo log和redo log的记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，当update一条记录时，它记录一条对应相反的update记录，当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。

undo log销毁: undo log 在事务执行时产生，事务提交时，并不会立即删除undo log，因为这些日子可能用于MVCC。

undo log存储: undo log 采用段的方式进行管理和记录，存放在前面介绍的rollback segment回滚段中，内部包含1024个undo log segment。

mvcc(multi-Version Concurrency Control),多版本并发控制，指维护一个数据的多个版本，使得读写操作没有冲突，快照读为MySQL实现MVCC提供了一个非阻塞读功能，MVCC的具体实现，还需要依赖于数据库记录中的三个隐式字段，undo log日志、readView。

read committed 每次select 都生成一个快照读

repeatable read 开启事务后第一个select语句才是快照读的地方

serializable 快照读会退化为当前读。

mvcc的实现原理

DB_TRX_ID: 最近修改事务ID，记录插入这条记录或最后一次修改该记录的事务ID

DB_ROLL_PTR: 回滚指针，指向这条记录的上一个版本，用于配合undo log，指向上一个 版本

DB_ROW_ID: 隐藏主键，如果表结构没有指定主键，将会生成该隐藏字段。

m_ids当前活跃的事务ID集合

min_trx_id: 最小活跃事务id

max_trx_id: 预分配事务ID，当前最大事务id+1，因为事务id是自增的

creator_trx_id: ReadView创建者的事务ID

版本链数据访问规则:

trx_id: 表示当前的事务ID

1、trx_id == creator_trx_id? 可以访问读版本-->成立的话,说明数据是当前这个事务更改的

2、trx_id 成立,说明数据已经提交了。

3、trx_id>max_trx_id？不可用访问读版本-> 成立的话，说明该事务是在ReadView生成后才开启的。

4、min_trx_id

7. 如何说服爸爸给我买电脑

哇....

好厉害的笔记本吖!

外星人笔记本电脑
处理器：AMD TR-3990X
主板：华擎 TRX-40 Creator
内存：金士顿 DDR4 3600 32G*8
硬盘：三星 980PRO 2TB*3
显卡：影驰 金属大师 RTX3090 OC Gamer
散热器：雅俊 ProArtist C7TR
风扇：超频三旋风F122+超频三旋风F92
电源：长城巨龙1650W
机箱：思戈拉N2

太厉害了!

那你自己是怎么想的，只是打算冷冷看，还是已经做了决定……

如果他真的跟她有什么，一般你不会那么容易发现……
如果他不在乎你们的感情了，你发现后，应该会表现的无所谓吧，还省的不知道怎么跟你谈……
他有回应过她发的消息吗
你发现后，就没给他解释的机会吗
不管是谁，都有可能被旁人惦记……

如果没打算分开，那么两个人好好聊聊吧，说出问题所在，看怎么解决更为妥当…

我也没有碰到过这方面的问题,哈哈!

有个人去赶集，半路上拉肚子，一时找不到厕所，正好看见路边有座正在施工的房屋，于是就跑进去方便，刚便完就被几个来盖房子的工人看见，工人们揪住他就要打。

这时，过路的老万看见了，大喝：你们为啥打人？！

工人们说：他在房里解手，这种人非揍不可。

老万说：你们不知道打人犯法嘛？！

工人就问道：那你说该杂办？

老万说：打人是不对的！他在房里拉了屎，你让他把拉出来的都吃回去不就行了吗，怎么能动手打人这么不讲道理呢?!

8. trx40配什么cpu有性价比

配酷睿i5-10400F性价好。
酷睿i5-10400F上市以来，一直都以低廉的价格揽住了很多电脑粉丝。而随着12代I5发布上市之后，i5-10400F的价格也有年下放，现在的价格大约800元左右。
华擎CreatorTRX40是一款电脑主板，主芯片组为AMDTRX40。