MySQL not using primary key on inner join
Notes


A FOREIGN KEY adds a constraint; it does not add an index if there is already one there.
Datatypes should match, but what you had was "close enough" for JOINing.
What was wrong -- The columns of an INDEX are looked at left-to-right.  Since there was no mention of processID (the first column), the index was not useful.
When JOINing, MySQL usually starts with one table, then repeatedly reaches into the other.  It picked lk.  Why?...
When practical, MySQL will start with the table that it can do some filtering on.  But neither table had any useful indexes.  So?...
As a fallback, MySQL starts with the 'smaller' table, lk_transaction_types and did a full table scan ("ALL").


To make the query more efficient, usually the filtering (WHERE) is tackled first:

WHERE l.escoID = 2
  AND lk.isActive = 1
  AND lk.isInbound = 1;


To help the Optimizer picks l as the first table, have

INDEX(escoID, ...)


Or, to help it pick lk, have

INDEX(isActive, isInbound, ...)  -- in either order


The ... is optionally more columns.

Without understanding the distribution of the data values, let me proceed with deriving the optimal indexes for each case.

SELECT  COUNT(0)
    FROM  edi.ediLoad l
    INNER JOIN  edi.lk_transaction_types lk
        ON lk.transactionTypeID =
            l.transactionTypeID
    WHERE   l.escoID = 2
      AND  lk.isActive = 1
      AND  lk.isInbound = 1;


Case:  Start with l:

l:   INDEX(escoID,             -- first, so as to satisfy `WHERE`
           transactionTypeID)  -- added to make the index "covering"


A "Covering index" contains all the columns (of one table) needed to satisfy the entire query.  This lets the processing work only in the index BTree, and ignore the Data BTree.

lk:  INDEX(isActive, isInbound, transactionTypeID)  -- in any order


Again, this is 'covering'.

Case:  Start with lk:

lk:  INDEX(isActive, isInbound,  -- first, in either order
           transactionTypeID)
l:   INDEX(escoID, transactionTypeID) -- in either order


In neither case was either PRIMARY KEY useful.  So, I claim your original question was ill-advised.  Instead, you should have asked "how can I make this query more efficient".  That is the question I have been answering.

One more thing.  Let's combine the two cases to minimize the number of indexes.

lk:  INDEX(isActive, isInbound,  -- first, in either order
           transactionTypeID)
l:   INDEX(escoID, transactionTypeID)  -- in this order


With InnoDB, the PK is "clustered" with the data. PRIMARY KEY(transactionTypeID) is sufficient for the second case, but not the first.

More on creating indexes.