Is there much difference between having a key (intA, intB), or having key (longAB) where longAB is the concatenation of bytes of intA and intB? This is a bit of an odd question.  Let's go with MySQL for example.  I don't know a ton about db internals.

Compare two scenarios, in one, we have a table with a composite key of the from (intA, intB).  Queries filter by range intA, and the intB portion of the key is to enforce uniqueness.  So we might do WHERE intA &gt; 0x123 AND intA &lt; 0xabc

The alternate scenario is where we have key (longAB), where longAB is the byte concatenation of intA and intB, in other words intA &lt;&lt; 32 | intB.  Now our queries look like WHERE longAB &gt; 0x12300000000 AND longAB &lt; 0xabc00000000

So we'd get back the equivalent rows.

My question is, would these have substantially different impact on space usage, IO intensity, and why?

Thanks
Worry about performance only after you've worried about the business.  If intA and intB are meaningful to the business, then NEVER EVER hide those attributes in columns that are "obfuscated" in the way you suggest.  Doing that WILL ALWAYS come back to haunt you.

You'll pay the price when someone wants to do a WHERE INTB = somevalue, and that moment WILL come.

With your design hack, the only way you could answer that question is by filtering the value out of your obfuscated column using some variant of MOD(yourcol,32BIT_MAX).  That means table scan by definition, unless you have been smart enough to also add an index on MOD(yourcol,32BIT_MAX).  But adding that index in addition to an index on yourcol is likely to make the overall solution SLOWER, precisely the opposite of what you were hoping to achieve.