You might be interested to read about ssdeep, a "context-triggered piecewise hash" (CTPH) used as a content-agnostic form of fuzzy hashing. Ssdeep builds hashes of pieces of a file so that similarity can be determined; say one character changes between two otherwise identical files. The checksum of the changed file parts will differ, but the checksums of all other parts will not, so the files are deemed to be highly similar.
You're essentially trying to do this but without intending to use it to measure file similarity.
I am under the impression that as long as you keep entire hashes (do not truncate them) and the segments you hash are large enough to make collisions rare (maybe 512 bytes?) then you will have a sufficient level of data integrity. It is theoretically possible that you'll have more integrity since you have a longer hash length, but there are so many areas that you have to be especially careful about in your implementation that I would not at all recommend this.
That said, you specified three sha256 hashes, including one for the whole file. As long as you're matching all three, this should be, at its weakest, as good as sha256 alone. It's likely stronger still, but you'll (probably) be just as susceptible as a single sha256 when it comes to theoretical SHA-2 vulnerabilities, so you might as well go for another algorithm such as SHA-3 or even (since you still have the full file's sha256) something faster like MD5. You can also consider storing the byte size.
256 bit SHA-2 should be sufficient for anything unless you're worried about the distant future. If that's the case, you can't take anything for granted, but I'd go with SHA2-512 and SHA3-512 and the exact file size.
If you just want more speed and aren't concerned with being attacked (i.e. you're just worried about data integrity from faulty hardware and/or crappy networks), you can start with just the file size, then calculate MD5 and SHA1 concurrently (two separate processes, one read of the file). I still wouldn't mess with cutting up a file unless you wanted to use ssdeep (which appears to use MD5 for its pieces by default).
Perhaps an attractive balance of speed and integrity could be to check the file size, then the MD5 of the first 5MB (or the whole file if under 5MB), then the real integrity check, e.g. sha256 or sha3-512. It should* be harder to create a collision and faster to detect failures (stop on the first failure) while being only negligibly slower than just the last check (it took me 0.003s to calculate the MD5 hash of a random 5MB test file). (* I'm expert in neither cryptoanalysis nor cryptographic checksums: this is not authoritative.)
I'm tempted to say that if an attack isn't suspected, you'd be fine with both file size and MD5 (you'd probably be fine with just MD5, though file size would allow you to fail faster and provide slightly better data integrity).