Have foreign key constraint and index key for the same column(s)
Constraints and Indexes serve two different purposes in the database.  

Constraints prevent data that violates the constraints from being stored in the database.  This protects future users of the data, but it limits flexibility and adds overhead.  For foreign key constraints such as the ones you have presented, the overhead is usually small, compared with the benefit of avoiding orphan references.

Indexes provide a map between key values and retrieval pointers.  SQL users never deal directly with retrieval pointers in SQL.  (Well, there are some dialects of SQL that let you do that, but it's generally a bad idea anyway.)  When the optimizer is evaluating strategies for retrieval, and estimating the cost, the presence or absence of an index may make the optimizer choose one strategy over another.  Sometimes the speed-up is dramatic.  Indexes cost a little space to store, and a little time to update when the data changes.  Some indexes are worth the cost, others are not.

In your case, I would play around with leaving out the index you've called fk_merchant_appointment.  It may be the case that MySQL will use the apointments_index instead, and get most of the benefits with less cost.  I can't say for sure.