Why does MySQL Workbench let me add unique indexes to primary keys?
Answer compiled from comments by:
Akina:
No reason for to restrict index creation when the statement is syntactically correct. The most common issue - CREATE TABLE t (id SERIAL PRIMARY KEY); which creates both UNIQUE index (due to SERIAL definition) and PRIMARY KEY (due to explicit specifying). So excess UNIQUE key must be removed by an additional statement.


To make this more confusing, this (upvoted) answer says:


This question deals with SQL Server and cannot be applied to MySQL. Check such moments carefully.

So could there be edge cases, or should I just cement in my memory to never think about UQ on a column that's already PK, and move on?

If you have PK then its expression is always unique, and you do not need in &quot;think about UQ on a column that's already PK&quot;. Additionally you may be sure that none column mentioned in PK expression definition is NULL (by default all such columns are defined as NOT NULL implicitly if there is no explicit option in column definition - check SHOW CREATE TABLE for this, fiddle).

...and Vérace:

or should I just cement in my memory to never think about UQ on a column that's already PK, and move on?

Yes, move on! Typically a UNIQUE index is for a natural primary key - and your PRIMARY KEY is for a surrogate. Purists aren't too keen on this approach, but it's more or less an industry standard.
There are cases where having a surrogate slows down the system.  A prime example is with many-to-many mapping tables where a composite PK is demonstrably better.
Just to add a word - the UNIQUE index for a natural primary key should include a NOT NULL for the relevant fields - one can have a UNIQUE index with NULL fields - because each NULL is neither equal to nor not equal to any other NULL or any other value. Take a look at this fiddle.
Would it be good Workbench were to suggest or enforce &quot;best practice&quot;?  If you think so, file it as an enhancement at bugs.mysql.com
Another &quot;suggestion&quot;:  INDEX(a) is redundant and wasteful if you also have INDEX(a,b).
A contrived use case:  SELECT id FROM tbl; would be more efficiently executed by scanning the UNIQUE index's BTree instead of scanning the PRIMARY KEY's BTree.  The former contains only id, the latter contains all the columns of the table.  (If you tack on a WHERE clause the references any other columns, then the PK's BTree will be the optimal.)