&gt; It can&#39;t be done, at least not in a precise way. &nbsp;There is no way to<br>&gt; know exactly which data a SQL statement will affect without actually<br>&gt; being able to fully execute the statement the same way your database
<br>&gt; would, at which point all the speed advantage is gone.<br><br>You are correct that one of the limitations of any analysis program is that unless it does full SQL parsing, there is no way to be sure your system isn&#39;t placed in an inconsistent state.&nbsp; However, in my application, updates are only performed using the primary key of the tables being updated (for performance reasons).&nbsp; This is true in all cases in my application, and thus it was relatively simple to write an analysis application that identified all queries that make updates.
<br><br><br>The method is not meant to provide a speed benefit, but rather a maintainability benefit.&nbsp; If your application is large enough, the maintainability penalty of using memcached becomes large.&nbsp; As the site points out, some applications (eg. Wikipedia/LiveJournal) have resorted to keeping a text file that lists all the memcached keys.&nbsp; Any time developers are making updates, they need to consult the text file (as well as the code) to make sure their changes aren&#39;t going to allow the system to be placed in an inconsistent state.&nbsp; In some cases, the method provides a slight (very small) decrease in performance, but in the system I&#39;m working on, the penalty is very small, and only incurred in a number of specific scenarios.
<br><br>It&#39;s clear that this isn&#39;t the ideal solution to the problem of maintaining cache consistency, but I&#39;ve found it quite effective in eliminating the maintainability penalty.<br>