1062 Duplicate entry but there are no duplicates? I keep getting this error: 


  failed to INSERT: [1062] Duplicate entry 'Upping Your Type
  Game-http://jessicahische.is/talkingtype' for key 'PRIMARY'.


The problem is, is that there are no duplicate entries. Which is why I'm confused when receiving that error.

Is there any way to check using InnoDB?

I have tried exporting the table and reading the SQL code and ran a search for any duplicates but there wasn't any.
It isn't saying that there is a duplicate entry in the table already, it is saying that there is already one entry in there with that value for the primary key and it is refusing to insert a second for that reason.

I suspect if you run: 

SELECT * 
FROM   &lt;table&gt; 
WHERE  &lt;keyfield&gt; = 'Upping Your Type Game-http://jessicahische.is/talkingtype'


or if that key is a composite 

SELECT * 
FROM   &lt;table&gt; 
WHERE  &lt;keyfield1&gt; = 'Upping Your Type Game' 
AND    &lt;keyfield2&gt; = 'http://jessicahische.is/talkingtype'


You will find one matching row, and that your code at the point of the error is trying to insert a second.

Dealing with duplicates on insert:

If you try INSERT a duplicate values for a primary key (or a unique index) you will always get that error. There are a couple of ways around it: check before you insert and either do an update (if something might have changed) or just don't do anything.

There is also the mysql specific ON DUPLICATE KEY UPDATE option (see https://stackoverflow.com/questions/1218905/how-do-i-update-if-exists-insert-if-not-aka-upsert-or-merge-in-mysql) if you are happy to sacrifice compatibility with other RDBMSs.

As of version 9.5 Postgres supports a similar feature with slightly different syntax (ON CONFLICT DO UPDATE/NOTHING - see https://wiki.postgresql.org/wiki/UPSERT).

MS SQL Server, Oracle and some other systems support MERGE statements as defined in the SQL:2003 standard (see https://en.wikipedia.org/wiki/Merge_(SQL)) which is intended to achieve the same functionality and more. Be careful with any of these options if cross database compatibility is (or is likely to be in future) one of your goals.