Answers.Body: <p>I've run into this as well. As Brad points out, this does appear to involve a bug in Craft's cache handling. HOWEVER, if you resort to caching only your HTML output, you don't reap the benefit of actually caching that big database query... What has worked for me is providing an explicit cache key:</p>
  
  <pre><code>{% cache globally using key craft.request.path ~ 'someDescriptive/identifyingName' %}
  </code></pre>
  
  <p>(I've been using descriptors in my cache keys because I've been needing to clear out various subsets of them very frequently, but you don't have to if you just have one <code>{% cache %}</code> fragment on a page.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-02-22T16:59:28.567Z
Answers.LastActivityDate: 2015-02-22T16:59:28.567Z
Answers.UserDisplayName: Michael Rog
Answers.Body: <p><strong>Update:</strong></p>
  
  <p>This has been fixed for the next (post <a href="http://buildwithcraft.com/updates#build2725" rel="nofollow">2.4.2725</a>) release.</p>
  
  <hr>
  
  <p>Turns out there is a bug in Craft where if you put cache tags around code that doesn't actually output anything, then duplicate keys get created in the <code>craft_templatecaches</code> table.</p>
  
  <p>No workaround for it yet (other than to make sure you don't cache an empty string), but it's been logged as a bug.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-02-21T06:07:32.480Z
Answers.Text: Copy that, thanks! Give a shout when it's patched, and we'll close this as a bug report. (In the meantime, it may still be useful for someone else to stumble upon.)
Answers.UserDisplayName: Lindsey D
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-08T12:42:38.993Z
Answers.Text: Now it's 6 months later - is this bug still open?
Answers.UserDisplayName: gromgull
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-09-08T17:34:25.683Z
Answers.Text: Still open... just make sure you're not caching an empty string as a workaround.
Answers.UserDisplayName: Brad Bell
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-02-21T00:38:47.867Z
Answers.LastActivityDate: 2015-11-20T19:14:21.020Z
Answers.LastEditDate: 2015-11-20T19:14:21.020Z
Answers.UserDisplayName: Brad Bell
Body: <p>Why would the <code>{% cache %}</code> tag be storing a new cache every time the page loads (instead of just loading the existing cache)?</p>
  
  <p>Unless I'm misunderstanding how caching works, the system should never record duplicate cache keys, correct?</p>
  
  <p><img src="https://i.sstatic.net/9DVJk.png" alt="enter image description here"></p>
  
  <p>Despite the data apparently getting cached, the page never feels like it's pulling from cache. Every page load feels long and sluggish.</p>
  
  <hr>
  
  <p><strong>UPDATE:</strong></p>
  
  <p>I've done some additional testing, and was able to get the caching to perform as expected. Here's what changed...</p>
  
  <p>In my original version, I was caching a giant chunk of the template. This included the large database query (100+ records with 100+ fields), some Twig-side data manipulation, and the entire HTML portion of the template. Within the HTML, I am looping through those records and rendering a chunk of HTML for each.</p>
  
  <p>In the new version, I am <strong>only caching the HTML loop.</strong> This is making a huge difference, bringing the page load time from ~15 seconds to ~1 second. </p>
  
  <p><strong>What I've found...</strong></p>
  
  <p>It appears that the offending line which was causing multiple cache keys to be generated is this one:</p>
  
  <pre><code>{% set entries = craft.entries.section('mySection').type('myType').limit(null).find %}
  </code></pre>
  
  <p>I still don't know why, and would appreciate an explanation if anyone knows!</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-02-10T23:19:43.377Z
Comments.Text: Hard to tell if this is going to be a bug or expected behavior because of so many variables. Any chance you could get it down to a simple, reproducible test case?
Comments.UserDisplayName: Brad Bell
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-02-10T23:36:38.647Z
Comments.Text: Wrap a `cache` tag around that `{% set entries %}` line, and that's basically my test case. If you'd like I can submit the whole thing to support@buildwithcraft.com (along with a DB export).
Comments.UserDisplayName: Lindsey D
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2015-02-10T23:48:34.237Z
Comments.Text: Sent from the Dashboard! Lemme know if you need anything else.
Comments.UserDisplayName: Lindsey D
Tags: <cache>
Title: {% cache %} always creates new cache data, never uses existing cached data
ThreadText: # {% cache %} always creates new cache data, never uses existing cached data
  
  (Asked by: username_0 on 2015-02-10)
  
  Why would the `{% cache %}` tag be storing a new cache every time the page loads (instead of just loading the existing cache)?
  
  Unless I'm misunderstanding how caching works, the system should never record duplicate cache keys, correct?
  
  ![enter image description here](https://i.sstatic.net/9DVJk.png)
  
  Despite the data apparently getting cached, the page never feels like it's pulling from cache. Every page load feels long and sluggish.
  
  ---
  
  **UPDATE:**
  
  I've done some additional testing, and was able to get the caching to perform as expected. Here's what changed...
  
  In my original version, I was caching a giant chunk of the template. This included the large database query (100+ records with 100+ fields), some Twig-side data manipulation, and the entire HTML portion of the template. Within the HTML, I am looping through those records and rendering a chunk of HTML for each.
  
  In the new version, I am **only caching the HTML loop.** This is making a huge difference, bringing the page load time from ~15 seconds to ~1 second.
  
  **What I've found...**
  
  It appears that the offending line which was causing multiple cache keys to be generated is this one:
  
  ```
  {% set entries = craft.entries.section('mySection').type('myType').limit(null).find %}
  
  ```
  
  I still don't know why, and would appreciate an explanation if anyone knows!
  
  **Tags:** cache
  
  > **Comments:**
  > **username_1**: Hard to tell if this is going to be a bug or expected behavior because of so many variables. Any chance you could get it down to a simple, reproducible test case?  
  > **username_0**: Wrap a `cache` tag around that `{% set entries %}` line, and that's basically my test case. If you'd like I can submit the whole thing to support@buildwithcraft.com (along with a DB export).  
  > **username_0**: Sent from the Dashboard! Lemme know if you need anything else.  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2015-02-21. Score: 6 | Accepted answer
  
  **Update:**
  
  This has been fixed for the next (post [2.4.2725](http://buildwithcraft.com/updates#build2725)) release.
  
  ---
  
  Turns out there is a bug in Craft where if you put cache tags around code that doesn't actually output anything, then duplicate keys get created in the `craft_templatecaches` table.
  
  No workaround for it yet (other than to make sure you don't cache an empty string), but it's been logged as a bug.
  
  > **Comments:**
  > **username_0**: Copy that, thanks! Give a shout when it's patched, and we'll close this as a bug report. (In the meantime, it may still be useful for someone else to stumble upon.)  
  > **username_3**: Now it's 6 months later - is this bug still open?  
  > **username_1**: Still open... just make sure you're not caching an empty string as a workaround.  
  
  ---
  
  ### Answer by username_2 on 2015-02-22. Score: 2
  
  I've run into this as well. As username_1 points out, this does appear to involve a bug in Craft's cache handling. HOWEVER, if you resort to caching only your HTML output, you don't reap the benefit of actually caching that big database query... What has worked for me is providing an explicit cache key:
  
  ```
  {% cache globally using key craft.request.path ~ 'someDescriptive/identifyingName' %}
  
  ```
  
  (I've been using descriptors in my cache keys because I've been needing to clear out various subsets of them very frequently, but you don't have to if you just have one `{% cache %}` fragment on a page.
  
  
  ---
  
  