Innodb full table Scan
It will do a full table scan.

The columns in an index are ordered.  Think about finding a person in a list of people where the list is sorted by last name, but all you know is the first name.

PRIMARY KEY(b,a)


would be somewhat good for WHERE b=1 AND c=2 -- it could at least narrow it down to all the rows where b=1.  That is, it would do a "range scan" of only part of the table.

INDEX(b,c)


would (probably) work better (given that you leave the PK at (a,b)).  This because it would drill down that secondary index's BTree to exactly the row(s) with (1,2), then reach over into Data+PK to find the rest of the columns needed.

No, don't even consider MyISAM these days.  There are more drawbacks than this one advantage -- if it even is an advantage.

See Cookbook for Creating Indexes.

More

The "left" part (b,a in this example) of the index can be directly used.

PRIMARY KEY(b,a,c,d) would benefit where b=1 and a=2 and d=3, but only because of b and a.  The BTree (actually a B+Tree) can efficiently be scanned.  The code would drill down to where b=1 and a=2 starts, then scan forward until b=1 and a=2 no longer applies.  c is in the way of making use of d=3, though it will be checked.

An InnoDB BTree are composed of 16KB block(s).  If you have only a few rows, every thing will be in one block.  If you have a billion rows, there may be many blocks for the b=1 entries, and the BTree may be about 5 physical levels deep of nodes pointing to sub-nodes.  The B+Tree means that it can scan one leaf node, then step right to the next leaf node.  A rule of thumb:  a block has 100 entries in it.  (In reality, it is anywhere from 1 to at least 1000, depending on a lot of things.)

One thing to remember in dealing with a MySQL PRIMARY KEY -- it is UNIQUE.  So don't randomly add/subtract columns from the definition; you will change what it is testing for uniqueness.