trx1a34

㈠ innodb存储引擎的数据文件放在哪里

MySQL数据库InnoDB存储引擎使用了B策略, InnoDB存储引擎中的恢复机制有几个特点：
A. 在重做Redo Log时，并不关心事务性。 恢复时，没有BEGIN，也没有COMMIT,ROLLBACK的行为。也不关心每个日志是哪个事务的。尽管事务ID等事务相关的内容会记入Redo Log，这些内容只是被当作要操作的数据的一部分。

B. 使用B策略就必须要将Undo Log持久化，而且必须要在写Redo Log之前将对应的Undo Log写入磁盘。Undo和Redo Log的这种关联，使得持久化变得复杂起来。为了降低复杂度，InnoDB将Undo Log看作数据，因此记录Undo Log的操作也会记录到redo log中。这样undo log就可以象数据一样缓存起来，而不用在redo log之前写入磁盘了。

包含Undo Log操作的Redo Log，看起来是这样的：

记录1: <trx1, Undo log insert <undo_insert …>>

记录2: <trx1, insert …>

记录3: <trx2, Undo log insert <undo_update …>>

记录4: <trx2, update …>

记录5: <trx3, Undo log insert <undo_delete …>>

记录6: <trx3, delete …>

C. 到这里，还有一个问题没有弄清楚。既然Redo没有事务性，那岂不是会重新执行被回滚了的事务？确实是这样。同时Innodb也会将事务回滚时的操作也记录到redo log中。回滚操作本质上也是对数据进行修改，因此回滚时对数据的操作也会记录到Redo Log中。

一个回滚了的事务的Redo Log，看起来是这样的：

记录1: <trx1, Undo log insert <undo_insert …>>

记录2: <trx1, insert A…>

记录3: <trx1, Undo log insert <undo_update …>>

记录4: <trx1, update B…>

记录5: <trx1, Undo log insert <undo_delete …>>

记录6: <trx1, delete C…>

记录7: <trx1, insert C>

记录8: <trx1, update B to old value>

记录9: <trx1, delete A>

一个被回滚了的事务在恢复时的操作就是先redo再undo，因此不会破坏数据的一致性.
- InnoDB存储引擎中相关的函数
Redo: recv_recovery_from_checkpoint_start()
Undo: recv_recovery_rollback_active()
Undo Log的Redo Log: trx_undof_page_add_undo_rec_log()

㈡ trx转账需要多少能量

转账1个TRR代币大概需要315能量。

转账TRC20代币或交易等，都会消耗能量和带宽。比如以转账TRR代币为例：转账89个TRR代币需要消耗345带宽和28031能量，该地址没有足够的能量，则抵扣了3.92434TRX作为手续费。

众所周知，波场代币主要分为TRC10和TRC20代币，资源主要分为三种：能量、带宽和存储。在波场独特的网络中，存储几乎是无限的。那么能量和带宽是有限的，用完了就需要花TRX来租赁或者冻结获得能量和带宽。

RC10代币是一种是通过TRON公链内置的通证。主要消耗带宽。

TRC20代币是在TRON区块链上通过部署智能合约的方式来发行资产的一套标准，主要消耗能量和带宽。

每个波场账户每天拥有1500带宽，用完会自动慢慢恢复至1500.目前转账TRC10代币一笔大概需要消耗300-400带宽，即每个账户每天可以免费转3-4笔TRC10代币，比如TRX。如果当日转账次数过多，没有足够的带宽来消耗，就会直接抵扣账户上面的TRX估为手续费。

能量是比较“珍贵”的资源了，账户每天没有免费的能量，如果想要获得能量有2种方式可以获得：

1、冻结TRX获得能量。TRON网络中冻结1万TRX，可以获得257431能量。

2、租赁。通过波场助手tronenergy.app能量平台，用1TRX可以租赁10800能量。