hibernate保存和更新实体类?

报错: A different object with the same identifier value was already associated with the session :
for 循环里 插入数据，最好是for循环完再flush。

数据添加可以累加后flush,但删除或修改数据一定要立马flush，且flush后，

数据会立马存储到数据里，后面的代码可以立即查询到，并且查询到后进行修改操作也是没有问题的。

如果10次循环，第6次出错的话，就用一个try catch,catch里用个flush即可。

那么前6次的数据依旧会保存。

数据有没有保存到 数据库的另一个关键是有没有commit()，也就是提交，这就需要到dao方法里看一下了。
且对于一个实体类，可以将其作为参数传到一个方法里，在方法里保存/更改和flush操作都是有用的，都会对库里数据造成实际影响。

13.7.6.3 FLUSH Statement



FLUSH [NO_WRITE_TO_BINLOG | LOCAL] {
    flush_option [, flush_option] ...
  | tables_option
}

flush_option: {
    BINARY LOGS
  | DES_KEY_FILE
  | ENGINE LOGS
  | ERROR LOGS
  | GENERAL LOGS
  | HOSTS
  | LOGS
  | PRIVILEGES
  | OPTIMIZER_COSTS
  | QUERY CACHE
  | RELAY LOGS [FOR CHANNEL channel]
  | SLOW LOGS
  | STATUS
  | USER_RESOURCES
}

tables_option: {
    TABLES
  | TABLES tbl_name [, tbl_name] ...
  | TABLES WITH READ LOCK
  | TABLES tbl_name [, tbl_name] ... WITH READ LOCK
  | TABLES tbl_name [, tbl_name] ... FOR EXPORT
}

The FLUSH statement has several variant forms that clear or reload various internal caches, flush tables, or acquire locks. To execute FLUSH, you must have the RELOAD privilege. Specific flush options might require additional privileges, as described later.

Note

It is not possible to issue FLUSH statements within stored functions or triggers. However, you may use FLUSH in stored procedures, so long as these are not called from stored functions or triggers. See Section 23.8, “Restrictions on Stored Programs”.

By default, the server writes FLUSH statements to the binary log so that they replicate to replication slaves. To suppress logging, specify the optional NO_WRITE_TO_BINLOG keyword or its alias LOCAL.

Note

FLUSH LOGS, FLUSH BINARY LOGS, FLUSH TABLES WITH READ LOCK (with or without a table list), and FLUSH TABLES tbl_name ... FOR EXPORT are not written to the binary log in any case because they would cause problems if replicated to a slave.

The FLUSH statement causes an implicit commit. See Section 13.3.3, “Statements That Cause an Implicit Commit”.

The mysqladmin utility provides a command-line interface to some flush operations, using commands such as flush-hosts, flush-logs, flush-privileges, flush-status, and flush-tables. See Section 4.5.2, “mysqladmin— Client for Administering a MySQL Server”.



Sending a SIGHUP signal to the server causes several flush operations to occur that are similar to various forms of the FLUSH statement. Signals can be sent by root or the account that owns the server process. They enable the applicable flush operations to be performed without having to connect to the server (which for these operations requires an account that has the RELOAD privilege). See Section 4.10, “Unix Signal Handling in MySQL”.

The RESET statement is similar to FLUSH. See Section 13.7.6.6, “RESET Statement”, for information about using theRESET statement with replication.

The following list describes the permitted FLUSH statement flush_option values. For descriptions of FLUSH TABLESvariants, see FLUSH TABLES Syntax.


	
FLUSH BINARY LOGS

	
Closes and reopens any binary log file to which the server is writing. If binary logging is enabled, the sequence number of the binary log file is incremented by one relative to the previous file.
	
	

	
FLUSH DES_KEY_FILE

	
Reloads the DES keys from the file that was specified with the --des-key-file option at server startup time.

	
Note

	
The DES_ENCRYPT() and DES_DECRYPT() functions are deprecated as of MySQL 5.7.6, will be removed in a future MySQL release, and should no longer be used. Consequently, --des-key-file and DES_KEY_FILE also are deprecated and will be removed.
	
	

	
FLUSH ENGINE LOGS

	
Closes and reopens any flushable logs for installed storage engines. This causes InnoDB to flush its logs to disk.
	
	

	
FLUSH ERROR LOGS

	
Closes and reopens any error log file to which the server is writing.
	
	

	
FLUSH GENERAL LOGS

	
Closes and reopens any general query log file to which the server is writing.
	
	

	
FLUSH HOSTS

	
Empties the host cache and the Performance Schema host_cache table that exposes the cache contents, and unblocks any blocked hosts. See Section 8.12.5.2, “DNS Lookup Optimization and the Host Cache”.

	
Flush the host cache if some of your hosts change IP address or if the error message Host 'host_name' is blocked occurs for connections from legitimate hosts. (See Section B.4.2.5, “Host 'host_name' is blocked”.) When more than max_connect_errors errors occur successively for a given host while connecting to the MySQL server, MySQL assumes that something is wrong and blocks the host from further connection requests. Flushing the host cache enables further connection attempts from the host. The default value of max_connect_errors is 100. To avoid this error message, start the server with max_connect_errors set to a large value.
	
	

	
FLUSH LOGS

	
Closes and reopens any log file to which the server is writing. If binary logging is enabled, the sequence number of the binary log file is incremented by one relative to the previous file. If relay logging is enabled, the sequence number of the relay log file is incremented by one relative to the previous file.

	
FLUSH LOGS has no effect on tables used for the general query log or for the slow query log (see Section 5.4.1, “Selecting General Query Log and Slow Query Log Output Destinations”).
	
	

	
FLUSH OPTIMIZER_COSTS

	
Rereads the cost model tables so that the optimizer starts using the current cost estimates stored in them. The server writes a warning to the error log for any unrecognized entries. (For information about these tables, seeSection 8.9.5, “The Optimizer Cost Model”.) This operation affects only sessions that begin subsequent to the flush. Existing sessions continue to use the cost estimates that were current when they began.
	
	

	
FLUSH PRIVILEGES

	
Reloads the privileges from the grant tables in the mysql system database.

	
If the --skip-grant-tables option was specified at server startup to disable the MySQL privilege system, FLUSH PRIVILEGES provides a way to enable the privilege system at runtime.

	
Frees memory cached by the server as a result of GRANT, CREATE USER, CREATE SERVER, and INSTALL PLUGINstatements. This memory is not released by the corresponding REVOKE, DROP USER, DROP SERVER, andUNINSTALL PLUGIN statements, so for a server that executes many instances of the statements that cause caching, there will be an increase in cached memory use unless it is freed with FLUSH PRIVILEGES.
	
	

	
FLUSH QUERY CACHE

	
Defragment the query cache to better utilize its memory. FLUSH QUERY CACHE does not remove any queries from the cache, unlike FLUSH TABLES or RESET QUERY CACHE.

	
Note

	
The query cache is deprecated as of MySQL 5.7.20, and is removed in MySQL 8.0. Deprecation includes FLUSH QUERY CACHE.
	
	

	
FLUSH RELAY LOGS [FOR CHANNEL channel]

	
Closes and reopens any relay log file to which the server is writing. If relay logging is enabled, the sequence number of the relay log file is incremented by one relative to the previous file.

	
The FOR CHANNEL channel clause enables you to name which replication channel the statement applies to. Execute FLUSH RELAY LOGS FOR CHANNEL channel to flush the relay log for a specific replication channel. If no channel is named and no extra replication channels exist, the statement applies to the default channel. If no channel is named and multiple replication channels exist, the statement applies to all replication channels, with the exception of the group_replication_applier channel. For more information, see Section 16.2.3, “Replication Channels”.
	
	

	
FLUSH SLOW LOGS

	
Closes and reopens any slow query log file to which the server is writing.
	
	

	
FLUSH STATUS

	
Note

	
The value of the show_compatibility_56 system variable affects the operation of this option. For details, see the description of that variable in Section 5.1.7, “Server System Variables”.

	
This option adds the current thread's session status variable values to the global values and resets the session values to zero. Some global variables may be reset to zero as well. It also resets the counters for key caches (default and named) to zero and sets Max_used_connections to the current number of open connections. This information may be of use when debugging a query. See Section 1.7, “How to Report Bugs or Problems”.
	
	

	
FLUSH USER_RESOURCES

	
Resets all per-hour user resources to zero. This enables clients that have reached their hourly connection, query, or update limits to resume activity immediately. FLUSH USER_RESOURCES does not apply to the limit on maximum simultaneous connections that is controlled by the max_user_connections system variable. See Section 6.2.16, “Setting Account Resource Limits”.
	
FLUSH TABLES Syntax

FLUSH TABLES flushes tables, and, depending on the variant used, acquires locks. Any TABLES variant used in aFLUSH statement must be the only option used. FLUSH TABLE is a synonym for FLUSH TABLES.

Note

The descriptions here that indicate tables are flushed by closing them apply differently for InnoDB, which flushes table contents to disk but leaves them open. This still permits table files to be copied while the tables are open, as long as other activity does not modify them.


	
FLUSH TABLES

	
Closes all open tables, forces all tables in use to be closed, and flushes the query cache and prepared statement cache. FLUSH TABLES also removes all query results from the query cache, like the RESET QUERY CACHEstatement. For information about query caching and prepared statement caching, see Section 8.10.3, “The MySQL Query Cache”. and Section 8.10.4, “Caching of Prepared Statements and Stored Programs”.

	
FLUSH TABLES is not permitted when there is an active LOCK TABLES ... READ. To flush and lock tables, useFLUSH TABLES tbl_name ... WITH READ LOCK instead.
	
	

	
FLUSH TABLES tbl_name [, tbl_name] ...

	
With a list of one or more comma-separated table names, this statement is like FLUSH TABLES with no names except that the server flushes only the named tables. If a named table does not exist, no error occurs.
	
	

	
FLUSH TABLES WITH READ LOCK

	
Closes all open tables and locks all tables for all databases with a global read lock. This is a very convenient way to get backups if you have a file system such as Veritas or ZFS that can take snapshots in time. Use UNLOCK TABLES to release the lock.

	
FLUSH TABLES WITH READ LOCK acquires a global read lock rather than table locks, so it is not subject to the same behavior as LOCK TABLES and UNLOCK TABLES with respect to table locking and implicit commits:

	

		
UNLOCK TABLES implicitly commits any active transaction only if any tables currently have been locked with LOCK TABLES. The commit does not occur for UNLOCK TABLES following FLUSH TABLES WITH READ LOCKbecause the latter statement does not acquire table locks.
		
		

		
Beginning a transaction causes table locks acquired with LOCK TABLES to be released, as though you had executed UNLOCK TABLES. Beginning a transaction does not release a global read lock acquired with FLUSH TABLES WITH READ LOCK.
		
	
Prior to MySQL 5.7.19, FLUSH TABLES WITH READ LOCK is not compatible with XA transactions.

	
FLUSH TABLES WITH READ LOCK does not prevent the server from inserting rows into the log tables (see Section 5.4.1, “Selecting General Query Log and Slow Query Log Output Destinations”).
	
	

	
FLUSH TABLES tbl_name [, tbl_name] ... WITH READ LOCK

	
This statement flushes and acquires read locks for the named tables. The statement first acquires exclusive metadata locks for the tables, so it waits for transactions that have those tables open to complete. Then the statement flushes the tables from the table cache, reopens the tables, acquires table locks (like LOCK TABLES ... READ), and downgrades the metadata locks from exclusive to shared. After the statement acquires locks and downgrades the metadata locks, other sessions can read but not modify the tables.

	
Because this statement acquires table locks, you must have the LOCK TABLES privilege for each table, in addition to the RELOAD privilege that is required to use any FLUSH statement.

	
This statement applies only to existing base (non-TEMPORARY) tables. If a name refers to a base table, that table is used. If it refers to a TEMPORARY table, it is ignored. If a name applies to a view, an ER_WRONG_OBJECT error occurs. Otherwise, an ER_NO_SUCH_TABLE error occurs.

	
Use UNLOCK TABLES to release the locks, LOCK TABLES to release the locks and acquire other locks, or START TRANSACTION to release the locks and begin a new transaction.

	
This FLUSH TABLES variant enables tables to be flushed and locked in a single operation. It provides a workaround for the restriction that FLUSH TABLES is not permitted when there is an active LOCK TABLES ... READ.

	
This statement does not perform an implicit UNLOCK TABLES, so an error results if you use the statement while there is any active LOCK TABLES or use it a second time without first releasing the locks acquired.

	
If a flushed table was opened with HANDLER, the handler is implicitly flushed and loses its position.
	
	

	
FLUSH TABLES tbl_name [, tbl_name] ... FOR EXPORT

	
This FLUSH TABLES variant applies to InnoDB tables. It ensures that changes to the named tables have been flushed to disk so that binary table copies can be made while the server is running.

	
The statement works like this:

	

		
It acquires shared metadata locks for the named tables. The statement blocks as long as other sessions have active transactions that have modified those tables or hold table locks for them. When the locks have been acquired, the statement blocks transactions that attempt to update the tables, while permitting read-only operations to continue.
		
		

		
It checks whether all storage engines for the tables support FOR EXPORT. If any do not, an ER_ILLEGAL_HAerror occurs and the statement fails.
		
		

		
The statement notifies the storage engine for each table to make the table ready for export. The storage engine must ensure that any pending changes are written to disk.
		
		

		
The statement puts the session in lock-tables mode so that the metadata locks acquired earlier are not released when the FOR EXPORT statement completes.
		
	
The FLUSH TABLES ... FOR EXPORT statement requires that you have the SELECT privilege for each table. Because this statement acquires table locks, you must also have the LOCK TABLES privilege for each table, in addition to the RELOAD privilege that is required to use any FLUSH statement.

	
This statement applies only to existing base (non-TEMPORARY) tables. If a name refers to a base table, that table is used. If it refers to a TEMPORARY table, it is ignored. If a name applies to a view, an ER_WRONG_OBJECT error occurs. Otherwise, an ER_NO_SUCH_TABLE error occurs.

	
InnoDB supports FOR EXPORT for tables that have their own .ibd file file (that is, tables created with theinnodb_file_per_table setting enabled). InnoDB ensures when notified by the FOR EXPORT statement that any changes have been flushed to disk. This permits a binary copy of table contents to be made while the FOR EXPORT statement is in effect because the .ibd file is transaction consistent and can be copied while the server is running. FOR EXPORT does not apply to InnoDB system tablespace files, or to InnoDB tables that have FULLTEXT indexes.

	
FLUSH TABLES ...FOR EXPORT is supported for partitioned InnoDB tables.

	
When notified by FOR EXPORT, InnoDB writes to disk certain kinds of data that is normally held in memory or in separate disk buffers outside the tablespace files. For each table, InnoDB also produces a file namedtable_name.cfg in the same database directory as the table. The .cfg file contains metadata needed to reimport the tablespace files later, into the same or different server.

	
When the FOR EXPORT statement completes, InnoDB will have flushed all dirty pages to the table data files. Anychange buffer entries are merged prior to flushing. At this point, the tables are locked and quiescent: The tables are in a transactionally consistent state on disk and you can copy the .ibd tablespace files along with the corresponding .cfg files to get a consistent snapshot of those tables.

	
For the procedure to reimport the copied table data into a MySQL instance, see Section 14.6.1.3, “Importing InnoDB Tables”.

	
After you are done with the tables, use UNLOCK TABLES to release the locks, LOCK TABLES to release the locks and acquire other locks, or START TRANSACTION to release the locks and begin a new transaction.

	
While any of these statements is in effect within the session, attempts to use FLUSH TABLES ... FOR EXPORTproduce an error:

	
FLUSH TABLES ... WITH READ LOCK
FLUSH TABLES ... FOR EXPORT
LOCK TABLES ... READ
LOCK TABLES ... WRITE

	
While FLUSH TABLES ... FOR EXPORT is in effect within the session, attempts to use any of these statements produce an error:

	
FLUSH TABLES WITH READ LOCK
FLUSH TABLES ... WITH READ LOCK
FLUSH TABLES ... FOR EXPORT
	

flush privileges的使用场景：

        当我们直接用DML语句修改系统权限表(mysql.user、mysql.db、mysql.tables_priv、mysql.columns_priv)时，内存中的权限数组是不会同步更新的，此时我们就需要flush privileges来更新内存权限数据了。

flush privileges 命令本质上的作用是将当前user和privilige表中的用户信息/权限设置从mysql库(MySQL数据库的内置库)中提取到内存里。MySQL用户数据和权限有修改后，希望在"不重启MySQL服务"的情况下直接生效，那么就需要执行这个命令。通常是在修改ROOT帐号的设f置后，怕重启后无法再登录进来，那么直接flush之后就可以看权限设置是否生效。

日志刷新策略

Kafka的日志实际上是开始是在缓存中的，然后根据一定策略定期一批一批写入到日志文件中去，以提高吞吐量.

log.flush.interval.messages 消息达到多少条时将数据写入到日志文件 10000

log.flush.interval.ms 当达到该时间时，强制执行一次flush  null

log.flush.shceduler.interval.ms 周期性检查，是否需要将信息flush