I have two tables, products and categories which have a many to many relationship, so I'm adding a products_categories table which will contain category_id and product_id.
Should I add another (auto-incrementing) index column or use the two existing ones as primary key?
That depends.
Are you seeing your data more as set of objects (and relational database is just a storage medium) or as set of facts represented and analyzed natively by relational algebra.
Some ORMs/Frameworks/Tools don't have good support for multicolumn primary keys. If you happen to use one of them, you'll need additional id column.
If it's just a many-to-many relationship with no additional data associated with it, it's better to avoid additional id column and have both columns as a primary key.
If you start adding some additional information to this association, then it may reach a point when it becomes something more then many-to-many relationship of two entities. It becomes an entity in it's own right and it'd be more convenient if it had it's own id independent to entities it connects.
You don't need to add an extra, auto-incrementing index column, but I (perhaps contrary to most others) still recommend that you do. First, it is easier in the application program to refer to a row using a single number, for example when you delete a row. Second, it sometimes turns out to be useful to be able to know the order in which the rows were added.
No, it's not necessary at all, given that these two columns are already executing the function of a primary key.
This third column whould just add more space to your table.
But... You could use it maybe to see the order in which your records where added to your table. That's the only function I can see to this column.
You don't need to add an auto-incrementing index column. Standard practice is to use just the two existing columns as your primary key for M:M association tables like you describe.
I would make the primary key category_id and product_id. Add an auto increment only if the order will ever be relevent in later uses.
There's a conceptual question - is products_categories an entity or is simply a table that represents a relationship between two entities? If it's an entity then, even if there are no additional attributes, I'd advocate for a separate ID column for the entity. If it's a relationship, if there are additional attributes (say, begin_date, end_date or something like that), I'd advocate to have a multi-column primary key.
