MySQL 连接缓存问题

[啵啵啃]

最近开发时遇到一个问题，请教一下各位大牛。
前提：1、两个数据库输入端，PC桌面软件使用MySQL C API开发;另有为手机端提动服务的webservice，使用 jdbc连接2、数据库为单点数据库，无主从。
现象：当手机端修改数据后，通过工具软件navicat可以看到数据库中数据已经修改，但是桌面端读出数据仍为原来的数据，未有修改。

疑问：首先我怀疑这是数据库缓存问题，但是数据库缓存的就数据在修改表后就会清空，按理说不应该出现这种状况。后来我反其道而行，通过桌面端修改，看手机端没有问题（实时被修改），因此排除了数据库缓存的问题。
然后我怀疑是因为长连接引起的，所以我将数据库连接改为每次查询之前进行连接，果然就能实时刷新了。那么问题来了，根据问题现象来看是每个连接有一个数据缓存，当连接关闭时清除（其实我试过，用该连接做一次更新操作也会清除缓存，但我总不能每次查询之前都更新一遍吧）。那么这个连接缓存是在数据库端还是在Connector C的lib库这边？应该怎么清除？或者说如何将这个连接的缓存设置成跟随表的变化而清空？不要说放弃长连接，因为数据库是远程的，经实际测试，长连接读写比每次现连接要快很多;也不要问我为什么要远程连接数据库，因为架构不是我做的

还请各位大牛指点迷津，怎么能解决这个问题，感激不尽啊！

[zjcxc]

试试在 read uncmmitted 和 read committed 下查询，如果前者看到是实时的，后者不是，那是事务没有提交 如果两都都是实时的，那说明你的连接开了事务，由于默认的事务隔离级别允许重复读，也就是在事物内，反复读取数据是读不到已经提交的数据变化的

[ACMAIN_CHM]

引用

The following list describes how MySQL supports the different transaction levels: READ UNCOMMITTED SELECT statements are performed in a nonlocking fashion, but a possible earlier version of a row might be used. Thus, using this isolation level, such reads are not consistent. This is also called a “dirty read.” Otherwise, this isolation level works like READ COMMITTED. READ COMMITTED A somewhat Oracle-like isolation level with respect to consistent (nonlocking) reads: Each consistent read, even within the same transaction, sets and reads its own fresh snapshot. See Section 13.6.8.2, “Consistent Nonlocking Reads”. For locking reads (SELECT with FOR UPDATE or LOCK IN SHARE MODE), InnoDB locks only index records, not the gaps before them, and thus allows the free insertion of new records next to locked records. For UPDATE and DELETE statements, locking depends on whether the statement uses a unique index with a unique search condition (such as WHERE id = 100), or a range-type search condition (such as WHERE id > 100). For a unique index with a unique search condition, InnoDB locks only the index record found, not the gap before it. For range-type searches, InnoDB locks the index range scanned, using gap locks or next-key (gap plus index-record) locks to block insertions by other sessions into the gaps covered by the range. This is necessary because “phantom rows” must be blocked for MySQL replication and recovery to work. Note In MySQL 5.4, if the READ COMMITTED isolation level is used or the innodb_locks_unsafe_for_binlog system variable is enabled, there is no InnoDB gap locking except for foreign-key constraint checking and duplicate-key checking. Also, record locks for nonmatching rows are released after MySQL has evaluated the WHERE condition. If you use READ COMMITTED or enable innodb_locks_unsafe_for_binlog, you must use row-based binary logging. REPEATABLE READ This is the default isolation level for InnoDB. For consistent reads, there is an important difference from the READ COMMITTED isolation level: All consistent reads within the same transaction read the snapshot established by the first read. This convention means that if you issue several plain (nonlocking) SELECT statements within the same transaction, these SELECT statements are consistent also with respect to each other. See Section 13.6.8.2, “Consistent Nonlocking Reads”. For locking reads (SELECT with FOR UPDATE or LOCK IN SHARE MODE), UPDATE, and DELETE statements, locking depends on whether the statement uses a unique index with a unique search condition, or a range-type search condition. For a unique index with a unique search condition, InnoDB locks only the index record found, not the gap before it. For other search conditions, InnoDB locks the index range scanned, using gap locks or next-key (gap plus index-record) locks to block insertions by other sessions into the gaps covered by the range. SERIALIZABLE This level is like REPEATABLE READ, but InnoDB implicitly converts all plain SELECT statements to SELECT ... LOCK IN SHARE MODE if autocommit is disabled. If autocommit is enabled, the SELECT is its own transaction. It therefore is known to be read only and can be serialized if performed as a consistent (nonlocking) read and need not block for other transactions. (This means that to force a plain SELECT to block if other transactions have modified the selected rows, you should disable autocommit.)

.

[ACMAIN_CHM]

既然navicat看数据已经被手机端更新了。说明数据库中记录已经被更新。 而PC端仍看不到，则一种可能是事务起了作用。

[啵啵啃]

引用 1 楼 ACMAIN_CHM 的回复:

既然navicat看数据已经被手机端更新了。说明数据库中记录已经被更新。 而PC端仍看不到，则一种可能是事务起了作用。

再询问一下，如果说是事务的话，那应该是说明手机端没有commit吧？如果手机端没有commit的话，我桌面端改成短连接应该也取不到更新后的收据啊？但现在的现象是如果桌面端改用短连接就可以实时取到最新数据，那是否说明是一个连接不断的话那么这个连接就一直有个缓存？麻烦指点一下，谢谢！